Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider the future of grid specifications #26

Open
bnlawrence opened this issue May 2, 2019 · 3 comments
Open

Consider the future of grid specifications #26

bnlawrence opened this issue May 2, 2019 · 3 comments

Comments

@bnlawrence
Copy link
Member

Currently we have gridspec, but it is not obvious that gridspec is the right kind of animal for the general software description of grids in simulation software descriptions. It might be a useful specialisation at some point, but higher level concepts appear to be necessary.

@bnlawrence
Copy link
Member Author

bnlawrence commented May 2, 2019

W. Deconinck et al. / Computer Physics Communications 220 (2017) 188–204 in their figure 4 have a useful ontology of types of grids:
Grids_DecEA17

The paper itself needs reading (especially section 3.2), but this snippet gives a flavour of the important bits:

For convenience the above concrete grids can be retrieved by a short grid identifier, e.g. O1280, in which the number represents the number of parallels between the North Pole (90◦ latitude) and equator (0◦ latitude). The grid identifiers for the grid classes RegularLonLatGrid, RegularGaussianGrid, ClassicGaussianGrid and OctahedralGaussianGrid are respectively L#, F#, N# and O#. These grid identifiers provide a common language to uniquely reference a grid in terms of resolution and category.
The classification further envisions to incorporate grids like the IcosahedralGrid, the CubedSphereGrid, and the YinYangGrid [31], which can be seen as combinations of sub-grids. These grids inherit from a class StructuredZonesGrid as illustrated in Fig. 4.
Listing 1 details how one can create the grids shown in Fig. 5 using either a grid identifier as described previously, or a Config object containing enough information to construct the correct grid. Such Config object could be constructed using JavaScript Object Notation (JSON), either programmatically (from a string) or from a file. Internally a Factory design pattern [32] is responsible for instantiating the correct concrete grid implementation.

@bnlawrence
Copy link
Member Author

It's a runtime configuration as to what the decomposition is ... so we need to think about having a sensible runtime configuration sitting inside the CIM as well ...

@bnlawrence
Copy link
Member Author

See also the specialisations:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant