Vertically stretched Cartesian grid

[ali-ramadhan]

Current operators assume constant Δz which allow the model to use faster operators and use a tiny bit less space, so they'd have to be rewritten a tiny bit to account for a variable Δz when that gets implemented.

We can either write new operators that get dispatched on HorizontallyRegularCartesianGrid structs (already possible), or maybe the performance gain is so tiny that we just make RegularCartesianGrid a subset of HorizontallyRegularCartesianGrid and only have one set of operators.

HorizontallyRegularCartesianGrid might be a descriptive but pretty bad struct name.

[glwagner]

Perhaps it makes sense to create a single issue for the addition of a new grid type, and keep track of all the various things that must be done to accommodate it there?

Note that this the addition of a new grid type doesn't create any problems in the code. The old functions will work just fine as-is provided you write new operators specifically for the new grid type.

[ali-ramadhan]

Good idea. I'll do that here but I'll keep the Poisson solver separate as that's a pretty nontrivial part of this.

And yes, we'd just need some new operators but since they're so similar to the old operators I'm wondering if it might make more sense to just get the two grids to share the same operators to cut down on the amount of code that needs to be maintained.

RegularCartesianGrid might slow down a tiny bit but most simulations will want more resolution near the boundaries anyways so HorizontallyRegularCartesianGrid might end up being faster for all practical cases in either case.

[glwagner]

I vote for writing new operators for new grid types. I think it makes sense to use the fastest algorithm available.

It is also potentially confusing to a future reader of the code if 'Δz' is --- unnecessarily --- an array of constants. I believe the code is clearer if the code structure, structs, etc reflect intent accurately and in detail. A regular grid has a constant Δz by definition; therefore, Δz should be a scalar.

You may find that regular grids have advantages and will be used often in the future. It is much easier to double the resolution of a regular grid, for example.

[ali-ramadhan]

Good idea. I'll do that here but I'll keep the Poisson solver separate as that's a pretty nontrivial part of this.

And yes, we'd just need some new operators but since they're so similar to the old operators I'm wondering if it might make more sense to just get the two grids to share the same operators to cut down on the amount of code that needs to be maintained.

RegularCartesianGrid might slow down a tiny bit but most simulations will want more resolution near the boundaries anyways so HorizontallyRegularCartesianGrid might end up being faster for all practical cases in either case.