Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Segfault somewhere in Henry's law coefficient definition

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

L

lnpilz

New member
Hi there,

I am getting a SIGSEGV somewhere in the definition of Henry's law coefficients when compiling with the intel compiler. With GCC everything works fine. I could trace the bug to somewhere below line 1976 in module_dep_simple.F, but couldn't track it further because inserting prints messes up the memory mapping and then sometimes the bug disappears or reappears somewhere else in the code.

I am running on Linux 2.6.32-754.29.2.el6.x86_64 and compiling with intel/18.0.1, intelmpi/2018.0.128. If you need any further info, please let me know.

Cheers,

Lukas
 
Hi Lukas,

Is your error occurring during the compile or the model run? If the latter, please delete chem/module_dep_simple.o and chem/module_dep_simple.mod, uncomment the FCDEBUG flags, and recompile. If the compile doesn't catch the problem, hopefully it will be discovered at runtime. Please also attach your compile log and rsl.out/error.0000 -

Which version of WRF-Chem are you using (feel free to attach module_dep_simple.F as well)

Jordan
 
Hi Jordan,

thanks for the reply. The error is occurring at runtime and I'm using WRF v4.2.1 (0d88b580).

Unfortunately I'm not too experienced with debugging Fortran, and didn't manage to make it work. After uncommenting the FCDEBUG flags and recompiling module_dep_simple.F, I don't even see a segfault anymore.

However, I got some help and the current theory is that the settings chem_opt=16, gas_drydep_opt=1 are causing this.

In chemics_init.f90:168
Code: 
numgas = get_last_gas(config_flags%chem_opt)
numgas is set to 0. This then calls dep_init in the WESELY case in drydep_select (chemics_init.f90:1978 and following).
Code: 
  drydep_select: SELECT CASE(config_flags%gas_drydep_opt)
     CASE (WESELY)
       CALL wrf_debug(15,'initializing dry dep (wesely)')

        call dep_init( id, config_flags, numgas, mminlu_loc, &
                      its, ite, jts, jte, ide, jde )
In dep_init (module_dep_simple.f90:1663 and following), the field dvj gets then initialized with size numgas, which is 0 here and thus any accesses are invalid, which leads to stack smashing.
Code: 
        REAL :: dat1(nlu,dep_seasons), dat2(nlu,dep_seasons),         &
                dat3(nlu,dep_seasons), dat4(nlu,dep_seasons),         &
                dat5(nlu,dep_seasons), dat6(nlu,dep_seasons),         &
                dat7(nlu,dep_seasons), dvj(numgas)

I hope you can reproduce this on your system.

Cheers, Lukas
 
Hi Lukas,

You are indeed correct. Numgas is set = 0 in module_input_chem_data.F As you can see, this chemistry option only includes GHGs and so you should set gas_drydep_opt = 0.

Jordan
 
Hi Jordan,

this sounds like a bug to me though. In my view the program should either fail and point out the conflicting options or choose sensible defaults dependent on chem_opt, but NOT carry on as if everything is fine with a smashed stack.

Do you want me to open an issue in the Github project for this?

Lukas
 
Hi Lukas,

Yes, a check and fatal call here would probably be best. If you are comfortable modifying the code, it would be most helpful if you submitted a pull request for this issue to the WRF github. You can find the template in your WRF installation: WRF/.github/PULL_REQUEST_TEMPLATE. Essentially you need to document the issue, modify the code, and show that your solution fixes the problem.

My suggestion would be to add a single check directly above CALL wrf_debug(15,'initializing dry dep (wesely)').

IF ( numgas .eq. 0 ) THEN
call wrf_error_fatal ( "ERROR: numgas = 0, SELECTED CHEM OPT IS NOT COMPATIBLE WITH WESELY DRY DEPOSITION" )
ENDIF

This way other schemes can be caught. If you aren't comfortable modifying and submitting the pull request, I will get it submitted and approved. I'm also happy to help you through the process if you would like to learn. Just let me know. Thank you for your help!

Jordan
 
Hi Jordan,

I implemented your solution in https://github.com/wrf-model/WRF/pull/1291, I think a fatal error there is indeed the best way of solving this. Feel free to check out the PR :)

Thanks a lot for your time and patience, Lukas
 
Hi Jordan,

independently from the PR: Do you know of any other possible hickups with chem_opt = 16, to be aware of?

Lukas
 
You must log in or register to reply here.
Top