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

Transfer CAM/CESM to WPS input

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.


New member
Hello everyone,
I am working on transferring the CAM/CESM data into WPS (ungrid) data.
I used a program from ""
Which can be used in the previous WRF/WPS v3.2
Now I want to use that with a newer version of WRF/WPS (v4.1).
From WRF/WPS v4.1, it seems that there is tropopause information, which did not provide by the previous WPS, and will fail when running the real.exe.

Is there any other methods that can help transfer CAM/CESM into WPS (with tropopause layer information), or how to set up a sudo-tropopause layer data which will not alter the WRF output?

Hello Ming Chen,
Sorry that I gave the wrong message. The real.exe will work but will fail when running the wrf.exe.
The error message as below,
Timing for processing lateral boundary for domain 1: 0.14277 elapsed seconds
Tile Strategy is not specified. Assuming 1D-Y
WRF TILE 1 IS 1 IE 125 JS 1 JE 125
PX LSM will use the MODIS landuse tables
Timing for Writing wrfout_d02_2021-06-01_00:00:00 for domain 2: 2.91683 elapsed seconds
forrtl: severe (174): SIGSEGV, segmentation fault occurred

I found that there are no tropopause data (TTROP, HGTTROP, ...), no max data (HGTMAXW, TMAXW, ...) and no SNOWH.
After I added those variables, (with values = 0), the WRF will work.

Rong-You Chien
Rong-You ,
Thanks for the update. I just have one question regarding this issue:
did you manually add TTROP, HGTTROP, HGTMAXW, TMAXW, SNOWH etc. to wrfinput, and then the previous failed case could work normally?
I am a little perplexed because these variables are not mandatory in wrfinput. I just run a case without these variables, and wrf.exe can still run successfully.
Hello Ming Chen,
I added them into the met_em.d0*.
I did not check if adding into the wrfbdy_d01 or wrfinput_d0* will alter that or not.
(But I also did not check whether they had these variables inside the real files).

I only tried adding those variables into met_em.d0* with different values, and see the values inside the wrfbdy_d01/wrfinput_d0* did not change.
So I am now manually adding zero to them.

Rong-You Chien