Hello.
I’m using the released version of CMAQv5.5. Unfortunately, I’m dealing with this error message:
Negative or Zero [H+] concentration specified in HLCONST
PM3EXIT: date&time specified as 0
Date&time specified as 0
I don’t know how to solve this error. Please, let me know if you need more information
Attached are the CCTM script and the log file.
run_cctm_Dominio1_FONDECYT.csh (39.1 KB)
CTM_LOG_005_v55_intel_Dominio01_Fondecyt_cb6r5_ae7_aq_m3dry_20190111.txt (89.3 KB)
Hi Ernesto,
Please recompile in debug mode, rerun the model, and report back whether the abort occurs in the same place. If it crashes, please provide the stack trace.
What landuse scheme and land-surface model did your WRF simulation use?
Dear @cgnolte . Thanks for your quick response.
I recompiled in debug mode and rerun the model, but it didn’t work. Unfortunately, I don’t understand what’s the error in the log files attached.
About the landuse scheme, I used Thermal Diffusion (option 1 in namelist.input for WRF simulation)
Please, if you help me solve this issue.
Best
run_cctm_Dominio1_FONDECYT_debug.csh (39.9 KB)
CCTM_36005431.txt (45.1 KB)
CTM_LOG_000.v55_intel_Dominio01_Fondecyt_cb6r5m_ae7_aq_m3dry_20190111.txt (106.5 KB)
The stack trace at the end of the CCTM_36005431.txt file indicates you are getting a divide by 0 error in m3dry. This is not my area of expertise, but there is likely an inconsistency between the land-water mask and the leaf area index, where some land grid cell (LWMASK=1) has a 0 value for LAI.
To verify whether that is the problem, you could run in a debugger, or just add a write statement prior to line 666 in m3dry.F, something like:
IF ( LAICR .EQ. 0.0 .OR. DIF0(L) .EQ. 0.0 ) THEN
WRITE(*,*) C,R, LAICR, DIF0(L)
END IF
As for how to fix this issue, if it is possible to rerun WRF you might do so with a different land-surface scheme, such as PX. You can try modifying m3dry to avoid these error conditions, but from reading the WRF documentation it seems the 5-layer thermal diffusion scheme is simplistic, with soil temperature only and without soil moisture, so I am not sure whether this can work with CMAQ.
Dear @cgnolte
Thanks again for your reply.
I added the statement you sent
I don’t know why this version of CMAQ has this kind of issue. I have used the same land-surface scheme with version CMAQ5.3 and it worked well. I suspect some mistake in the new m3dry.F file
The underlying issue appears to be that you have grid cells where the MCIP (WRF) LWMASK field equals 1 (i.e. land) but the LAI field (and likely VEGF field) equals 0. This is not a situation expected in the m3dry code. To determine where and why this happens, you’d probably have to dig into the WRF preprocessing and the WRF LSM code to determine how LWMASK, LAI, and VEGF are handled.
In previous versions of the code, the if/then block starting on line 516 defined the “water” case as
IF ( ( NINT(GRID_DATA%LWMASK( c,r )) .EQ. 0 ) .OR. ( vegcr .EQ. 0.0 ) ) THEN ! water
In CMAQv55, this block was updated to only rely on LWMASK to determine whether a grid cell should be treated as water (in which case LAI isn’t needed) or land (in which case non-zero LAI is needed):
IF ( NINT(GRID_DATA%LWMASK( c,r )) .EQ. 0 ) THEN ! water
We would have to talk to the developer why this change was made. In any case, if my assumption is right that you have (unrealistic, or at least unexpected by m3dry) grid cells with LWMASK = 1 but LAI = VEGF = 0, the previous code would have protected you because VEGF = 0 would have branched these grid cells to the water case where LAI is not needed but the new code will branch these cells to the land case where the LAI = 0 value will cause a problem.
Dear @hogrefe.christian
Thanks for your reply for this post.
I changed the line 516 as you mentioned and it worked. So, now I’m confused about what statement must be. At least, the issue was identified and the solution is shown for other users.
Best
Hello Ernesto,
to help us better understand why you encountered a situation where LWMASK was 1 but VEGF and LAI were 0, could you please share which landuse scheme you used in your WRF simulations and whether your wrfout files contained variables VEGFRA and/or LAI?
Thanks,
Christian
Dear @hogrefe.christian
The landuse scheme is “Thermal Diffusion”.
In this link you can download one of the wrfout files to view the VEGFRA and LAI variables and their information. Hope this could help you to understand this issue.
Hello Ernesto,
thank you for posting the wrfout file. It seems your landuse scheme (not land-surface model) was MODIFIED_IGBP_MODIS_NOAH.
Looking at the LWMASK, LAI, and VEGFRA fields, the problem likely originates over Antarctica and the Atacama desert with zero LAI values. If you had used the PX LSM in WRF, it would have prevented the divide-by-zero issues in the CMAQ m3dry deposition calculations because it assigns non-zero but very small minimum vegetation fraction and LAI values even to the snow/ice and barren/sparsely vegetated MODIS landuse categories (see this piece of WRF code).
Hello Ernesto,
after some discussions with the developer, rather than reverting the IF statement on line 516 in CMAQv5.5 to the earlier version, it might also work to change lines 665 and 666 from
rstom = MET_DATA%RS( c,r ) * dwat / dif0( l )
& + 1.0 / ( heff_ap / 3000.0 + 100.0 * meso( l ) ) / laicr
to
rstom = MET_DATA%RS( c,r ) * dwat / dif0( l )
& + laicr / ( heff_ap / 3000.0 + 100.0 * meso( l ) )
If it works, it would be preferable since the code would then treat ozone deposition to grid cells in Antarctica (snow/ice land use) and desert areas as land-based deposition which would have higher rates than deposition to water.
Hello,
I am using the released version of CMAQv5.5.
I also encountered this bug, so I changed lines 665 and 666 in m3dry.F.
It worked!
Then, I tried to compile the “large” version of CMAQv5.5 to run the ISAM version and ensure that variables can exceed 2048 to 16384.
However, I encountered the same bug again. Even after modifying lines 665 and 666 in m3dry.F, unfortunately, it didn’t work.
Are there any ways to resolve this problem?
It is unexpected that changing I/O API from the standard to the “large” version would have any impact on whether this portion of the m3dry code encounters this particular error.
Could you please compile in debug mode, post the log files, verify that your latest build includes the modified version of m3dry.F with the changes to lines 665 and 666 rather than the original file copied from the code repository (for debugging purposes, you could add some print statement to the modified file so that your CCTM log file confirms the use of the modified file), and share which WRF LSM and landuse scheme you were using? As discussed above, this error likely can also be avoided by using the PX LSM in WRF, which would also provide greater consistency with the dry deposition calculations in CMAQ.