Compiling issue after adding variables to tslist in WRF 4.4.2

[userwrfch]

Hi,

I am using WRF 4.4.2. and wanted to add a few 2d variables (albedo, swdown, sr, hgt) to tslist, but WRF doesn't compile anymore after doing so. I followed this post (which is written for an older version). I have also tried to use an old version of share/wrf_timeseries.F from my previous WRF installation (4.1.3) where I had already successfully added the variables to tslist, but using this old file in 4.4.2 doesn't work either. WRF 4.4.2 compiled fine without the changes in tslist.

Could you please help me what to do? I have attached the relevant files (had to add .txt to be able to upload them). I am compiling WRF with option 34 (GNU and distributed memory MPI) and then 1 (basic nesting).

Thanks!

 

[kwerner]

Hi,
In your compile log, this is the first error I see:

module_domain_type.f90:5150:53:

module_domain_type.f90:3048:53:

 real      ,DIMENSION(:,:)     ,POINTER   :: ts_swdown
                                                     2
module_domain_type.f90:5150:53:

 real      ,DIMENSION(:,:)     ,POINTER   :: ts_swdown
                                                     1
Error: Component ‘ts_swdown’ at (1) already declared at (2)

Did you also make modifications to the module_domain_type.F file? If so, can you attach that, as well?

If the only two files you modified are Registry.EM_COMMON and wrf_timeseries.F, can you try to compile again, using only a single processor this time?

./clean -a
./configure
./compile em_real -j 1 >& log.compile.txt

and then send the new compile log? Thanks!

 

[userwrfch]

Thank you for your help! Here is the new compile log with only a single processor. I did not make modifications to the module_domain_type.F (the only two files I modified are Registry.EM_COMMON and wrf_timeseries.F).

 

[kwerner]

It's really odd that it's complaining about that file. Can you also send me these 2 files, just so I can take a look at the lines it's complaining about?
frame/module_domain_type.F
frame/module_domain_type.f90

 

[userwrfch]

Yes, please find attached these files.

 

[kwerner]

Thank you for sending those. Okay, the issue causing the first error in the compile log is related to the fact that the variable "ts_swdown" is already included in the wrf_timeseries.F file, but is specifically related to WRF-Solar. This means it's also in the Registry/registry.solar_fields file, which is what adds it to the module_domain_type.f90 file during the build. This means you don't need to add it to Registry.EM_COMMON because it's then being added to module_domain_type.f90 twice, which is causing the issue.

A second issue you would have eventually encountered is that the new file endings were added to both the WRF_CHEM and the basic WRF sections, and the value for TS_FIELDS was not updated for basic WRF (after the "else" in the code section below). I assume you're NOT running WRF-Chem, and if that's the case, the first section can be left as default. I.e., TS_FIELDS = 8 and the file endings only go through "O3." Then TS_FIELDS should equal 11 in the second section.

#if (WRF_CHEM == 1)
   INTEGER, PARAMETER :: TS_FIELDS = 12
   CHARACTER (LEN=2), DIMENSION(TS_FIELDS) :: &
      ts_file_endings = (/ 'UU', 'VV', 'PH', 'TH', 'QV' ,'WW', 'PR', 'O3', 'AL', 'SW', 'SR', 'HG'/)
#else
   INTEGER, PARAMETER :: TS_FIELDS = 7
   CHARACTER (LEN=2), DIMENSION(TS_FIELDS) :: &
      ts_file_endings = (/ 'UU', 'VV', 'PH', 'TH', 'QV' ,'WW', 'PR', 'AL', 'SW', 'SR', 'HG'/)
#endif

so that it now should read

#if (WRF_CHEM == 1)
   INTEGER, PARAMETER :: TS_FIELDS = 8
   CHARACTER (LEN=2), DIMENSION(TS_FIELDS) :: &
      ts_file_endings = (/ 'UU', 'VV', 'PH', 'TH', 'QV' ,'WW', 'PR', 'O3'/)
#else
   INTEGER, PARAMETER :: TS_FIELDS = 11
   CHARACTER (LEN=2), DIMENSION(TS_FIELDS) :: &
      ts_file_endings = (/ 'UU', 'VV', 'PH', 'TH', 'QV' ,'WW', 'PR', 'AL', 'SW', 'SR', 'HG'/)
#endif

Additionally, there was one line in the wrf_timeseries.F file that would eventually cause you problems. Line 486 in the file you sent was written as

grid%ts_hgt(n,i)  = grid%hgt(ix,iy)

However, there is no variable called 'hgt' in the code. That needed to be modified to just 'ht' on the right side of the equation.

grid%ts_hgt(n,i)  = grid%ht(ix,iy)

I did a test compile, making the modifications to those files, and it compiled without issues. I'm attaching the files (which are the same as yours, but with the new modifications). Place these files in their correct locations and make sure to change "Registry.EM_COMMON.txt" to "Registry.EM_COMMON."

Registry/Registry.EM_COMMON
share/wrf_timeseries.F

then from the top-level WRF directory, issue a "clean -a," reconfigure, and then recompile. Let me know if that helps. Then let me know whether you actually get the intended time series printouts when you run wrf. You may want to first do a short/small test to just be sure.

 

[userwrfch]

Thank you very much for your help! WRF compiles well with the file that you created, but when I did a test run to check for the time series output, the output for swdown is not correct (not physical; it seems that in that column the albedo column is just replicated). The output for the other added variables (albedo, sr, hgt) seems fine though. I have attached a time series output file.

 

[kwerner]

Hi,
I just want to let you know that I'm seeing the same result you are - no values for SWDOWN. I've been trying to figure out why this is happening, but haven't found the solution yet. I'll keep you posted when I figure something out.

 

[kwerner]

Can you attach your namelist.input file and your tslist, and let me know where your domain is located? Thanks!

 

[userwrfch]

Hi,
I am very sorry for the late reply, somehow my notifications turned off.
Please find attached the namelist.input and tslist files.
Thank you!

 

[kwerner]

Thanks! Can you also please let me know where your domain is located (or you can just attach the namelist.wps file so I can determine based on the lat/lon settings)?

 

[userwrfch]

Here is the namelist.wps file. Thanks!

 

[kwerner]

Apologies for the delay. I've been trying to work on this off and on and may have a solution for you. The difference in the time-series code between the older (v4.1) code and the version you're using v4.4.2 is the addition of wrf-solar code in the newer version. The wrf-solar code also contains the ts_swdown variable, and I haven't figured out why, but I think that has something to do with why you aren't getting the correct values for only that particular output. I was finally able to get some reasonable values if I used a different name (e.g., ts_swdown1, instead of ts_swdown). Can you give that a try and see if it gives you the results you desire?