Add cartesian projection

[lpilz]

Change Summary

Added cartesian projection in grid treatment. This will cause the transformation (L64/66) to be an identity transformation. There could also be an argument for raising an error and just skipping the creation of the CRS and these coordinates as the idealized lat/lons probably don't correspond to actual coordinates.

Related issue number

Closes #163

Checklist

• Unit tests for the changes exist
• Tests pass on CI
• Documentation reflects the changes where applicable

[lpilz]

I didn't create tests for this as we don't have any idealized files in xwrf-data. @MaxEtherington could you maybe share some?

[jthielen]

My instinct would be skipping grid/projection handling for this case rather than adding a possibly fictitious (since there isn't really a datum or projection to be referred to?) identity transformation, but having no real experience with idealized WRF output, I'd definitely defer to others with more experience. In any case, I'd agree that there should be at least some test of this (either way it is implemented) before going in.

[lpilz]

I see your point, @jthielen - was thinking the exact same thing. However, since we probably still want to create the coordinate values for the south_north/west_east and especially the *_stag dimensions I figured this would be the least invasive change. What do you think of the following?

@MaxEtherington what do you think of this implementation? And could you provide us with test files?

[MaxEtherington]

Hi! Apologies for not getting back to you — I've been out on a geology mapping trip for the last week, and internet access has been correspondingly patchy.

Regarding implementation, skipping the creation of a CRS seems best; in the simulations I've run, ideal.exe simply rips the input lat/lon from namelist.input and applies the same values uniformly to every cell in the grid. That is to say, those 'coordinates' don't resemble anything real.

The wrfoutput files I've been working with are somewhat hefty (1.5–3.5 GB); how much would you like me to trim them down? How many timesteps would be useful? I'm admittedly fairly new to Github — what would be the best way to share them with you?

[lpilz]

Thanks for your reply. I'm fine with just not creating the CRS. In the end, if you're using idealized WRF runs, you should know what you are doing as a user.

Regarding the data, I would ask you to make a pull request in the xarray-contrib/xwrf-data repo adding the respective file with a sensible name like ideal.nc. I think just one timestep with one sensible variable (so including XLAT, TIMES and so on) is good, this should hopefully bring it down to a manageable size. Please consult the documentation on how to create a pull request. If you're stuck, I'm happy to help.

[lpilz]

@jthielen I added just one small test for the ideal file because the XLAT/XLONG coordinates don't seem to be sensible (they are all one value). If you have any further ideas what to test, let me know. Otherwise this would be good to go from my POV

[mgrover1]

@lpilz - I have a sample dataset we can pull in here - I wonder if we just make the projection optional as well, as we do with other postprocessing steps?

[mgrover1]

same thing here - let me know if you need a review @lpilz

[lpilz]

@lpilz - I have a sample dataset we can pull in here - I wonder if we just make the projection optional as well, as we do with other postprocessing steps?

Thanks! We already have a dataset in xwrf-data but if you think that there is something missing, we can of course add yours as well :)

Regarding the projection: That's probably a good idea, refactoring it to make it more intuitively useable was something that was on my mind anyways... Let's discuss this in a new issue.

same thing here - let me know if you need a review @lpilz

And if you could review, that would be great :)

[mgrover1]

Looks good to me - thanks @lpilz !