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

Additional variables output from physics module

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.

lkugler

New member
Hi all,
I read somewhere that a variable one wants to output, needs to be defined as state variable in the Registry (Registry.EM_COMMON) like this (defines the variable QFX, which already is in the output file)
Code:
state    real  QFX              ij      misc        1         -      rh       "QFX"                   "UPWARD MOISTURE FLUX AT THE SURFACE"          "kg m-2 s-1"
where "h" in "rh" stands for "history", i.e. the output in the wrfout_d01_.... NETCDF standard output history files.

Can I add any variable as state variable? Especially a locally defined one (in some physics module)?

For example EETA (transpiration), which is defined in the module_sf_ruclsm. (at the physics layer). Gill WRF I/O states "Local variables inside of physics packages are not controlled by the Registry". So do I need to initialize EETA to the variables in module_surface_driver.F?

I copied the line from QFX and changed the variable name to EETA, but it failed when executing wrf.exe in ./frame/module_domain.F on line 1174

Code:
WRITE(mess,*)'W A R N I N G : Unable to modify mask for ',TRIM(lookee),&
             '.  Variable not found. File: ',TRIM(fname),' at line ',lineno

Thanks for any hint on that.
Regards,
Lukas
 
Lucas,

To add a variable to standard output history file, you need to define this variable as a state variable in Registry.EM_COMMON, and make it included in wrfout by adding 'h' in the 8th column of the definition (QFX is a good example to follow).

You will also need to pass this variable from the physics to the driver. Then type ./clean -a and rebuild WRF.

We have a presentation here that might also be helpful. Please see http://www2.mmm.ucar.edu/wrf/users/tutorial/201801/registry.pdf

Ming Chen
 
Hi Lucas!

I have the same problem as you have and I am interested in FLX1, FLX2 and FLX3 in the Noah LSM physics package. How do I "lift" them up from the physics package up to the driver? I presume that it is the physics driver? After I have lift it to the driver I need to define it as a state variable in the registry_EM_COMMON?

If you(or someone else) have done this for your variable and have the time to explain to me how you did i would be greatful!!! :)

Cheers,

Martin Hagman
 
Hi Martin,
The driver you would be interested in for the Noah LSM is module_sf_noahdrv.F. It looks like FLX1/2/3 are already included in the driver in the call to SFLX. You will still need to incorporate them into the Registry.EM_COMMON file as a state variable, and you can follow the QFX example given above in this post.
 
Hi Kelly,

I have followed your instructions and added FLX1, FLX2 and FLX3 as state variables in Registry.EM_COMMON. I cleaned, reconfigured and recompiled and got the variables in my output_NetCDF-file. So far so good, but..........when I look at the variables they are all the time 0....

In one of the attached files I made a screen dump from Registry.EM_COMMON. In the other I took a snapshot from the output when I started wrf.exe. It says that history stream 10 is chosen for the variables, but I have read somewhere that this stream is reserved to nudging.... Can this have something to do with my problem?

I am running the WRF Single column model now so it is pretty easy for me to do new runs. I have added a lot of cloud water for my run, so there is a lot of precipitation. The period is January and February 2018 in Sodankylä in northern Finland so there is a lot of snow on the ground and the temperatures is below zero. In this situation FLX1, 2 and 3 can't be zero all the time I think.....

Is it sure that the only thing I really need to do is to add the variables as state-variables in the Registry for this case.... I mean, is it possible to get zero for the variable, because it is not found, or would I have got an error while compiling in that case?

I am very thankful for help!

//Martin
 

Attachments

  • Skärmavbild 2018-11-28 kl. 13.25.26.png
    Skärmavbild 2018-11-28 kl. 13.25.26.png
    517.8 KB · Views: 2,588
  • Skärmavbild 2018-11-28 kl. 22.48.53.png
    Skärmavbild 2018-11-28 kl. 22.48.53.png
    146 KB · Views: 2,585
Martin,
Can you tell me which version of WRF you are using? Can you also attach your namelist.input file?
When you say that the variables print out in time 0, do you mean they are available at the initial time period, but not in steps after that?
Thanks.
 
Hi again Kelly!

I am using WRFV3.9.1.1.

No, I am meaning that the variables have the value of 0 AT EVERY TIMESTEP. Since I wrote last time I have put print-statements for the variables in Noah Land Surfce model driver. As I suspected they are NOT zero.

Hope you understand better now! :)

I attach my namelist.input.

//Martin
 

Attachments

  • namelist.input
    4.4 KB · Views: 84
Hi,
I'm sorry to bother you again, but can you also send your "myoutfields.txt" file? I apologize for not thinking to ask for this last time.
Thanks,
Kelly
 
Hi Kelly!

I had totally forgot that I had put FLX 1,2 and 3 in my "myoutpufields.txt". It was before I put the variables in the Registry and recompiled.

Apparently the file said: +:h:10:FLX1,FLX2,FLX3, so that is where output stream number 10 came from. I don't know why I chose outputstream 10...

Anyway, I made the file empty and ran the model again. The variables are still 0 in the historyfile, but not when I look at the ouput from the print statements. So, the problem still exists....

What I am trying to figure out in a larger perspective is my energy balance at the surface. According to this I use following lines in a Python script to calculate it myself(TIDSLANGD means number of timesteps):



[GLW = Filobjekt.variables['GLW'][0:TIDSLANGD, 1, 1]
SWDOWN = Filobjekt.variables['SWDOWN'][0:TIDSLANGD, 1, 1]
GRDFLX = Filobjekt.variables['GRDFLX'][0:TIDSLANGD, 1, 1]
HFX = Filobjekt.variables['HFX'][0:TIDSLANGD, 1, 1]
LH = Filobjekt.variables['LH'][0:TIDSLANGD, 1, 1]
EMISS = Filobjekt.variables['EMISS'][0:TIDSLANGD, 1, 1]
ALBEDO = Filobjekt.variables['ALBEDO'][0:TIDSLANGD, 1, 1]
FLX1 = Filobjekt.variables['FLX1'][0:TIDSLANGD, 1, 1]
FLX2 = Filobjekt.variables['FLX2'][0:TIDSLANGD, 1, 1]
FLX3 = Filobjekt.variables['FLX3'][0:TIDSLANGD, 1, 1]

SWUP = ALBEDO*SWDOWN
GUPLW = EMISS*5.67e-8*(TSK+273.15)**4


RESIDUAL = GLW + SWDOWN - SWUP - GUPLW - HFX - LH + GRDFLX - FLX1 - FLX2 - FLX3



I want to compare my RESIDUAL to the NOAHRES variable from the Noah Land surface scheme:

NOAHRES = Filobjekt.variables['NOAHRES'][0:TIDSLANGD, 1, 1]

NOAHRES is defined like this in Noah lsm driver(with my write statements below):

! Residual of surface energy balance equation terms
!
noahres(i,j) = ( solnet + lwdn ) - sheat + ssoil - eta &
- ( emissi * STBOLT * (t1**4) ) - flx1 - flx2 - flx3
WRITE(*,*)"MH FLX1=",FLX1
WRITE(*,*)"MH FLX2=",FLX2
WRITE(*,*)"MH FLX3=",FLX3

RESIDUAL and NOAHRES are not the same, which is strange. It is exactly the same signs in my equation as in the model, where I have seen that LH is the same as ETA, SSOIL is the same as GRDFLX and HFX is the same as SHEAT. I suppose that is right, or?

So the first thing I want to see is if the FLX-variables can be responsible for this... I don't think so, because they seem too small. Anyway, at the moment they are ZERO at every timestep in my equation, so it is difficult to really verify this hypotheses.



Another reflection :

In the description of ETA and SHEAT in module_sf_noahlsm.F it says that SHEAT is positive UP FROM SURFACE and that ETA is NEGATIVE up from surface, but the variables has THE SAME sign in the equation in the model:

noahres(i,j) = ( solnet + lwdn ) - sheat + ssoil - eta &
- ( emissi * STBOLT * (t1**4) ) - flx1 - flx2 - flx3


SHEAT SENSIBLE HEAT FLUX (W M-2: POSITIVE, IF UPWARD FROM
! SURFACE)'

ETA ACTUAL LATENT HEAT FLUX (W m-2: NEGATIVE, IF UP FROM
! SURFACE)

Thanks for your time Kelly!

//Martin
 
Martin,
I just want to let you know that I haven't forgotten about this. I've had a couple of deadlines this week, but I'll hopefully get some helpful information to you early next week. Thank you for your patience.
Kelly
 
Martin,
Okay, so since FLX1,FLX2,FLX3 are local variables they will need to be passed into the surface driver and into the solver, in addition to the registry. They will also need to be converted into a 2d array. I have made the necessary modifications to the V3.9.1.1 files and am attaching them. You'll need to place the files in their correct directories:
Registry/Registry.EM_COMMON
phys/module_sf_noahdrv.F
phys/module_surface_driver.F
dyn_em/module_first_rk_step_part1.F

I tested this with a small/simple case to ensure they weren't all zero, and it seems to work okay. Because there is a modification to the registry, you'll need to issue a 'clean -a' before reconfiguring and recompiling. I'd recommend running a short case first just to ensure that you are seeing the output as you expect.

Kelly
 

Attachments

  • module_first_rk_step_part1.F
    99.7 KB · Views: 90
  • module_sf_noahdrv.F
    234.1 KB · Views: 91
  • module_surface_driver.F
    347.6 KB · Views: 99
  • Registry.EM_COMMON
    365.2 KB · Views: 103
Kelly,
thanks a lot! I haven't tried yet but I will. Just to understand....in an earlier mail you wrote:

''Hi Martin,
The driver you would be interested in for the Noah LSM is module_sf_noahdrv.F. It looks like FLX1/2/3 are already included in the driver in the call to SFLX. You will still need to incorporate them into the Registry.EM_COMMON file as a state variable, and you can follow the QFX example given above in this post.''

So that wasn't true, or were the fluxes incorporated in module_sf_noahdrv.F, but not in the module_surface_driver.F or the dyn_em/module_first_rk_step_part1.F?

And for shure it will be a small run, because I am running the SCM. :)

Thanks again, Kelly!

//Martin
 
Martin,
I originally thought it would be fine to use the code as-is, but I did end up needing to make some modifications to the Noah driver. So you'll just want to disregard any modifications you previously made, and start fresh with the files I attached yesterday. Hopefully this will work okay with the SCM. I tested this with a real case. Keep me posted!
Kelly
 
Top