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

Strange Stripes in MPAS Output

M

MattW

Member
Hi MPAS Folks,

I've noticed some strange stripes in the near-surface fields of a recent MPAS simulation I ran, and I was wondering if any of you have seen something similar before? They show up in the 2m temperature, soil temperature, 10 m wind, and skin temperature fields, but I haven't seen them in the lowest model level temperature field or any field above the ground, which makes me think they're related to land surface conditions. However, I haven't been able to find them in the static or init files I used to run this simulation so far. I've attached an image of the skin temperature from this experiment--the stripes show up most clearly near the Rio Grande, but are present in much of the rest of the image.

Thanks,

Matt 1755030295876.png
 
Matt,

Would you please give me more information on your case:

(1) Is this a global or regional MPAS run? Which version of MPAS are you running?

(2) What is the input data for this case?

(3) Please upload your namelist and stream files for me to take a look.

(4) if you run this case in derecho, please tell me where the case is located.

Thanks.
 
Sure!

1) This is a regional simulation in a 1 km domain covering most of TX. It uses v8.3 of MPAS (although it is the NOAA-GSL branch, I'll also be asking them about the stripes but I figured I'd also ask here in case you'd seen the problem as well).

2) The input data for this case was from the 00 UTC HRRR on 4 July 2025.

3) / 4) I ran this case in /glade/derecho/scratch/mawilson/mpas_tests/TX_floods. I just ran a CONUS-scale simulation in this directory as well on a 3 km grid (which was how I found this error, I just used output from the 1 km run as an example because the stripes show up better) using basically the same namelists (only the dates, timestep, and domain change), so the namelist.atmosphere and streams.atmosphere files in that directory should also reproduce the error. I've uploaded those files here.
 

Attachments

  • namelist (1).atmosphere.txt
    2.4 KB · Views: 1
  • streams (1).atmosphere.txt
    2.5 KB · Views: 1
Hi Matt,

In your namelist.atmopshere, you set config_physics_suite = 'hrrrv5'. Would you please clarify what physics schemes are used in this suite?

In addition, I found that you set "config_len_disp = 3000.0". For your case with the finest mesh of 1km, please set "config_len_disp = 1000.0"

The time interval for radiation calculation is 15min, which is way too large for the 1km run. Would you please change them to 1 or 3 min, i.e.,

config_radtlw_interval = '00:3:00'

config_radtsw_interval = '00:3:00'

Would you please change the above options, especially the config_len_disp, then try again?

Please let me know whether the strip feature is removed in your new run. Also, please keep me updated if you have any feedback from GSL.

Thanks.
 
Hi Ming,

Following up on this, the hrrrv5 suite contains TEMPO microphysics, MYNN PBL and sfc layer, RRTMG SW/LW radiation, and RUC land surface schemes.

I tried re-running my simulation with the changes you suggested (setting config_len_disp to 3000 and using a 3 minute interval for the radiation calculations) and unfortunately the stripes still exist. However, I also tried running a separate simulation (with the same namelist) on a regional 3 km mesh covering the CONUS extracted from the global 3 km mesh available from the MMM site, and that simulation didn't have the stripes. The two simulations with the stripes were on custom 1- and 3-km meshes I created using a custom mesh creation tool (MPAS-BR/grids/utilities/jigsaw/spherical_grid.py at master · pedrospeixoto/MPAS-BR), so I think the custom mesh was the problem. At some point I might still need to run some 1-km simulations--is there a pre-created 1 km mesh out there somewhere I can subset a regional domain from or a good tool to use to make one?

Thanks!

-Matt
 
Hi Matt,

Thank you for the update. Unfortunately we don't have 1-km MPAS mesh.

Have you ever talked to professor Pedro Peixoto regarding the mesh issue you have found? I am thinking whether he can figure out what is wrong in his script .....

Please keep me updated if you find a way to fix the mesh issue. I suppose this information will be helpful for other users who want to create their own meshes. Thanks in advance.

Ming
 
I've got an update on this issue! I talked to Pedro Peixoto and he noticed that my earlier mesh had 72 obtuse triangles in it, which might be the source of the errors I was encountering. I remade the mesh with a much larger transition zone between the 1 km mesh and the outer, global mesh, which resulted in a new mesh with no obtuse triangles. I then extracted a regional mesh from this one and tried to run a regional MPAS simulation on it using HRRR data as IC/BCs. I sucessfully generated the .init and lbc files, but unfortunately I'm now getting an error stating that the surface energy budget crashes whenever I try to run MPAS with these inputs. I've tried this with two different cases from the HRRR (just in case it was bad input data) and got the same result for both cases. Any ideas on what might be crashing the surface energy budget? The directory I'm running this case in is /glade/derecho/scratch/mawilson/mpas_tests/custom_mesh if you want to take a look.

Thanks,

Matt
 
Matt,

I found many NaN values in your file "TX_region.static.nc", ---- is this the file you used to produce initial and LBC files for regional MPAS run?
 
That would probably explain the errors--which fields were the NaNs in? I can check if they're in the file I subset the regional file from (globe1.static.nc) as well.
 
Just look at 'ter': ncdump -v ter TX_region.static.nc | grep -i NaN ==> you will see many NaNf

I guess you need to recreate static data for your regional domain. Please set the following options, then rerun init_atmosphere to create static data.

config_supersample_factor = 9
config_lu_supersample_factor = 3
config_30s_supersample_factor = 3

Let me know after you finish recreating static.nc file. I will double check to make sure it is correct.
 
Just created a new static.nc file (TX_mini2.static.nc) and it seemed to have a NaN-free ter field (at least when I checked in Python). However, when I used it to create .init and lbc files and tried to run MPAS with them, I still got the same surface energy budget crash error. Is there something else that might be causing it?
 
Please clarify what "surface energy budget crash error" is shown in your log file.

Which version of MPAS are you running? Can you upload your namelist.atmosphere for me to take a look?
 
The error unfortunatly isn't very specific, it says "Error: crash in surface energy budget / CRITICAL ERROR: MPAS core_physics abort". I've uploaded copies of one of the error files and the namelist.atmosphere for you to take a look at. The version of MPAS I'm using is version 8.3.0-1.6 from the UFS community git repository.

Thanks,

Matt
 

Attachments

  • log.atmosphere.0701.err.txt
    471 bytes · Views: 1
  • namelist (2).atmosphere.txt
    2.4 KB · Views: 0
Any updates on this? I'm currently testing out whether setting config_blend_bdy_terrain=true makes a difference for this error, so I'll let you know if that works.

Thanks,

Matt
 
Matt,

I haven't found time to explore your issue because I am busy with a user's case that crashed for unknown reason.

In addition, you use MPAS from UFS community, which is not the MPAS officially released by NCAR MMM, --- this adds extra workload for me to investigate specific features in the UFS MPAS.

Have you talked to NOAA people regarding your problem?
 
You must log in or register to reply here.
Top