Run MPAS with GFS data - Problem

[Helber Gomes]

Dear Everyone,


  I'm trying to run the MPAS with GFS data. I get only the data analysis (gfs.t00z.pgrb2f00 and rtgssthr_grb_0.083.grib2) and I generate the files FILE:2013-07-02_00 and SST:2013-07-02_00. The namelists are in attachments.

I'm wanting to run 5 days with output every 6 hours and all physical options.

You could give me a hand please?

PS: I need to have the files FILE and SST for all times as the WRF?  I'm in doubt because the MPAS is a global model and I believe it will only need the initial time. Is this correct?

Best regards,
Helber

[du...@ucar.edu]

Hi, Helber.

You're correct in that MPAS only requires data at the initial time, since we have no lateral boundaries. The only data source that you may want to provide at other times in your simulation would be SST and sea ice data: for longer simulations, MPAS has the option of updating the SST and sea ice fields from a surface update file (created by initialization case 8), since these fields would otherwise not change in the simulation.

Your namelist.input.init_atmosphere_static file looks fine, and I can offer a few suggestions for the other namelists.

In the case that you only want to provide an alternate SST field (other than what comes with the GFS) at the initial time, you don't need to run initialization case 8, which is used to produce a surface update file to update the SST and sea ice fields periodically during the model simulation. You can then get rid of the namelist.input.init_atmosphere_surface namelist, and instead introduce the RTG SST data into your initial conditions by setting "config_sfc_prefix = 'SST'" and "config_input_sst = .true." in your namelist.input.init_atmosphere_vertical file.

Since the GFS dataset only has 26 pressure levels, plus a surface level, you'll need to change config_nfglevels in your namelist.input.init_atmosphere_vertical to 27. Also, I believe that the GFS data are only provided up to 10 hPa, which may at certain times and locations be lower in height than your specified model top of 30 km; so, it might be safer with GFS (or other datasets that don't provide data significantly above 30 km) to lower your model top to, say, 29 km.

In your namelist.input.atmosphere, it's important to note that any namelist options that aren't explicitly set will take on their default values from src/core_atmosphere/Registry.xml; some of these variables must be set based on the model resolution, so you'll likely not want the default values, which are generally set for a global 120-km mesh. For the mesh with 655362 cells -- approximately a global 30-km grid -- I'd recommend adding config_len_disp = 30000.0 and config_visc4_2dsmag = 0.05 to the namelist. It might also be a good idea to turn on the w-damping layer by adding config_zd = 22000.0 and config_xnutr = 0.2.

Hopefully these changes will help in getting an initial simulation to run. If you have other questions, please don't hesitate to ask.

Regards,

Michael

[Helber Gomes]

Hi Michael,

  First I would like to thank you for your feedback.

I made all the changes you suggested and the MPAS model really it all worked out. He managed to write two output files and then was aborted.
The message given was:

=====================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   EXIT CODE: 11
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
=====================================================================================
APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault (signal 11)

I'll try with another resolution to see if it is a memory problem. What do you think about this?

Thank you very much.

regards,
Helber

[Helber Gomes]

Hi Michael,

I tried with a lower resolution and the problem continues. I'm not using the RTG SST data. I'm just using GFS data. Attached is the error log.

Regards,
Helber

[Helber Gomes]

Hi Michael,

  The model is running. I'm running with a lower resolution (120km). I believe the problem was in config_dt. After this test I will test again with a resolution of 30km.

Thank you very much.

Regards,
Helber

[du...@ucar.edu]

Hi, Helber.

It looks like the model may be going unstable based on the maximum velocities in the last timestep before the model crashed:

 global min, max w   -954.57928579785926        812.56754104821573

 global min, max u   -724.46929195364578        691.80580932584951

 global min, max scalar   1  0.0000000000E+00  0.2677679352E-01

 global min, max scalar   2  0.0000000000E+00  0.1483584408E-02

 global min, max scalar   3  0.0000000000E+00  0.4485372018E-02

 global min, max scalar   4  0.0000000000E+00  0.1612152592E-01

 global min, max scalar   5  0.0000000000E+00  0.8831282491E-01

 global min, max scalar   6  0.0000000000E+00  0.1811247855E+00

 global min, max scalar   7  0.0000000000E+00  0.0000000000E+00

 global min, max scalar   8  0.0000000000E+00  0.0000000000E+00

As you suggest in your next post, this might just be an issue of choosing a smaller timestep (config_dt).

Best regards,

Michael

[du...@ucar.edu]

Out of curiosity, what timestep are you able to successfully run with on the 120-km mesh? In any case, it's good to hear that you've got MPAS-A running!

Regards,

Michael

[Helber Gomes]

Hi Michael,

 I'm using a timestep equal to 500. He also works with timestep equal to 540. I will now test with 30-km mesh and timestep equal to 100.

Thank you very much.

Regards,
Helber