Size of lfric domain

[iboutle]

Is there a way in lfric_atm to obtain the total size of the domain, e.g. total number of cells, number of cells on a panel side - not hugely bothered exactly what, just something that gives an idea of the total number of grid-points we have?

There is already one namelist item specifying something akin to the C number, which has to be changed every time the resolution is changed, and I'm about to add a 2nd (slightly different entry), but it feels like this information should be obtainable from the mesh!

[Matthew Hambley (MatthewHambley)]

If there's anything like that in the namelists it should be hunt down and shot. Mesh information should come from the mesh and there should never be double entry book keeping.

Please explain your requirements and I'll see what we can do.

[Mike Hobson (mike-hobson)]

As Matthew says, that is mesh information, so should come from the mesh, definitely not from a namelist. I'm not sure we have that information in the mesh at the moment (which is probably why someone's put it in a namelist). Meshes are mostly concerned with the mesh for their partition, so don't have much global info like total number of cells in the whole domain. But, again, as Matthew says, if you have a requirement, we can get hold of that sort of number from the global mesh (which is a bit trickier, now we have off-line partitioning).

[iboutle]

The current namelist entry is "model_wavenumber_max" in the stochastic physics namelist. This is the maximum spectral wavenumber the scheme can resolve, which equals the number of equatorial grid-points / 2, or equivalently the C-number * 2.

The one I'm currently looking at is an iterative solver for mean-sea level pressure, where in the UM the number of iterations scales like the number of grid-points in the domain. Initially I'm going to specify the number of iterations in the namelist, to do some exploration of how many are actually needed, but it may be that we want to link this to domain size again (it makes sense why larger domains / higher resolution models will require more iterations).

I think if we could obtain the C-number (global) or nx/ny points (limited area) from the mesh information, that would cover all requirements, as anything else can be derived from that.

[Ricky Wong (mo-rickywong)]

The global mesh object (2D) file will have a ncells dimension, the local mesh object has two methods:

procedure, public :: get_num_panels_global_mesh
procedure, public :: get_ncells_global_mesh

A mesh object has a pointer to the local mesh it was generated from, which in turn can be queried with the above method to get the number of cells per panel. This information is is the mesh file that is read it, As Mike and Matthew we shouldn't be specifying it in namelists unless it is solely to check that the mesh you are reading in meets a certain criteria (and aborting if it doesn't).

[iboutle]

Thanks Ricky - I think that's what I'm after. In fact I can even see that there is a function which uses them called:

get_cubesphere_resolution

in jedi_lfric_mesh_interface - not sure if it's possible to use this in lfric_atm, but will give it a try

[Ricky Wong (mo-rickywong)]

Don't use that, it's a bit unsteady in terms of what its intended for, I'm not sure jedi knows want it wants. I wouldn't go building on anything in there. Jedi components aren't really components and probably should be there at all.

[Andrew Coughtrie (andrewcoughtrie)]

Hi Ian, If that `get_cubed_sphere_resolution` subroutine is the one in JEDI-LFRic component then it shouldn't be used in lfric_atm directly, It may be possible to move it to the driver component; failing that you should create your own.

[iboutle]

Yep, you're right it doesn't work.

I've tried using the things Ricky points to directly, but get the compile error:

Error: 'get_ncells_global_mesh' at (1) is not a member of the 'linked_list_data_type' structure

any ideas?

[iboutle]

Ah, I see - I need to get the local_mesh first!