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

Segmentation fault with real.exe and MOZCART

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.

Hi all,

I am facing a problem when I run real.exe using the chemistry (chem_opt= 112), the code stops after looking for "Subroutine input_chem_profile" with a segmentation fault, while if I do not use chemistry (chem_opt=0) or other chemistry (i.e. chem_opt =300) not related to MOZART gas phase, I have not problem.

I have read something about, and it seems to be a memory limit problem, but I have already set "limit stacksize unlimited' on my enviroment and, I used the code successfully before (with the same namelist and domain), so I can't understand what is happening.

Someone adviced me to set "chem_in_opt =1", but the model stops since I do not have the "wrf_chem_input_d01" (actually I have nevere used before).

WRF-Chem is compiled with the traceback option. If you open the rsl.error.0009 attached you can see the backtrace error.

I opened the module_input_chem_data, and I noticed that he problem is that the "is" indice is equal 0, since "iref" is 0

in the module_input_chem_data.F:

Code:
847 !UMM = Update Mauro Morichetti     

 848 !print*,'iref',iref

 849       DO  l=2, numgas

 850          is=iref(l-1)

 851          DO j=ny1,ny2

 852          DO k=nz1,nz2

 853          DO i=nx1,nx2

 854             chem(i,k,j,l)=fracref(l-1)*stor(i,k,j,is) * 1.E6

 855          ENDDO

 856          ENDDO

 857          ENDDO

 858       ENDDO

I looked trough the code and I found that "iref" is defined and associated to a precise value, for different subroutines (i.e., setup_gasprofile_map_saprcnov, setup_gasprofile_map_radm_racm...). For the "SUBROUTINE make_chem_profile" it is defined, but it has not a value associated. So I copied the lines 411-413 (the iref for SUBROUTINE setup_gasprofile_map_radm_racm)

from:

Code:
 411   iref(:)    = 7 !default value

 412   iref(1:41) = (/12,19,2,2,1,3,4,9,8,5,5,32,6,6,6,30,30,10,26,13,11,6,6, &

 413                  14,15,15,23,23,32,16,23,31,17,23,23,23,23,23,7,28,29/)

to:

Code:
797 !UMM = Update Mauro Morichetti     

 798     iref(:)    = 7 !default value

 799     iref(1:41) = (/12,19,2,2,1,3,4,9,8,5,5,32,6,6,6,30,30,10,26,13,11,6,6, &

 800                  14,15,15,23,23,32,16,23,31,17,23,23,23,23,23,7,28,29/)

Now the real.exe (with chemistry) is running, but I would like to understand why it is happing. As I said before I have already used the same simulation (setting, physics, chemistry, domain) without problem, and I have read different people with the same problem, so I believe could be a bug or something.

Any Ideas?

Thanks
 

Attachments

  • namelist.MM.txt
    9.5 KB · Views: 42
  • rsl.error.0000.MM.txt
    2.3 KB · Views: 39
  • rsl.error.0009.MM.txt
    2.4 KB · Views: 39
  • rsl.out.0000.MM.txt
    8.3 KB · Views: 37
Hi,

I'm having a little trouble following - Can you please post the original file and what you modified? The "iref" and "fracref" variables are not consistent across mechanisms as the follow the order of the species in the Registry. For example, RADM/RACM's first few species are: so2,sulf,no2,no,o3,hno3,h2o2,... whereas, for mozcart: o3,o1d_cb4,o,no,no2,no3,n2o5,hno3,hno4,so2,ho,ho2,h2o2, and so you won't be able to switch one subroutine for another.

I don't typically use the MOZART related chemical mechanisms but it seems as though they are only set up to run with initial conditions from another model simulation (i.e., chem_in_opt = 1). You may also want to look into the mozbc program developed by NCAR. I will look at this in more detail.

Jordan
 
Hi Jordan,

first of all, thanks for your reply, and sorry if I have responded now, but I didn't real someone answered to the topic.

I know that iref depends on the chemical mechanism, in fact for MOZCART iref should be not considered.

I don't typically use the MOZART related chemical mechanisms but it seems as though they are only set up to run with initial conditions from another model simulation (i.e., chem_in_opt = 1). You may also want to look into the mozbc program developed by NCAR. I will look at this in more detail.

You can use initial condition from another simulation, but it is not required. MOZBC not depends on this option.

Anyhow, I tried another test, I used iref=7 (default) so the real.exe is arrived to the end with not errors, the problem now is that wrf.exe crashes with no errors. Attached the original and mofdified modules (look for UMM, they are my updates).

After some tests I make a step back. I used this configuration before succesfully, so I replicated a identical copy of WRF-Chem in an other supercomputer, and guess what? I haven't had any kind of problems.

So I compared the two enviroment:

1) WRF-Chem not working:

Code:
/hpc/home/join22/WRF-4.1.3/chem/ dmesg | grep -i "linux version" | head -1
[    0.000000] Linux version 4.18.0-147.el8.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Wed Dec 4 21:51:45 UTC 2019

2) WRF-Chem working on:

Code:
/home/morichetti/ dmesg | grep -i "linux version" | head -1
[    0.000000] Linux version 3.13.0-170-generic (buildd@lcy01-amd64-001) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.4) ) #220-Ubuntu SMP Thu May 9 12:40:49 UTC 2019 (Ubuntu 3.13.0-170.220-generic 3.13.11-ckt39)

So it is possible that there are some problems with the gcc 8.3.1 in some way?

Thanks

Mauro
 

Attachments

  • module_input_chem_data.original.F
    153.1 KB · Views: 42
  • module_input_chem_data.modified.F
    153.4 KB · Views: 47
Top