geodynamics / aspect

A parallel, extensible finite element code to simulate convection in both 2D and 3D models.
https://aspect.geodynamics.org/
Other
223 stars 235 forks source link

Best way to read in temperature grids #3976

Open paddywball opened 3 years ago

paddywball commented 3 years ago

Hi Team,

I have a file of regularly spaced (Longitude, Latitude, Depth, Temperature) points which I would like to use within Aspect as a temperature field for a global-scale model. There is a function in structured_data.h/structured_data.cc to do this task already (StructuredDataLookup). However, this function reads ascii files with a specific header, and my data is in xml files. It would be trivial for me to convert my data into the required ascii format, but I was wondering whether it would be better in the long run to include the option of reading in xml files?

If using xml files, or another file format, is preferred to ascii let me know and I would be happy to try and write an additional file reader. But if it makes no difference to the Aspect team which file formats are used I can just convert to ascii.

Let me know which is best!

gassmoeller commented 3 years ago

Hi Paddy, I think having the ability to read in xml files in addition to the ascii files would be really nice to have. The StructuredDataLookup class was renamed (from AsciiDataLookup) a while ago to make it more general for other file formats. Do you think your application could essentially reuse much of that class and maybe add the functionality to read .xml to the load_file function? One question I have would be about the structure of the xml file. As far as I know it is not unique how to store the data in there, so I guess you have some special format (like say one field specifying x coordinates, one field y coordinates, one field temperatures)? Once we fix that format all xml files for ASPECT would need to follow this format. So if you have an example file, could you post it here?

We already have one plugin that reads in xml-like data (boundary_velocity/gplates.cc), however that is for a very specific xml format and the code is already pretty old (so maybe not a great model). Nevertheless, if you want to take a look that plugin could give some hints on how to implement this.

paddywball commented 3 years ago

Hi Rene, Glad you think adding this functionality would be worthwhile, and I agree it should be as general as possible. At the moment my file is structured as shown below, which is essentially x, y, z, value:

-180.0 -90.0 50.0 1774.13901143 -180.0 -89.0 50.0 1817.12912177

.....etc

if you think I should change this format in some way let me know. Thanks for the plugin suggestion! I will try and get something together based on this as a model, I'm no expert ASPECT user, so even if it is a little outdated I'm sure it will be much better than starting from scratch.

paddywball commented 3 years ago

Sorry copy pasting code didn't work.... Here is the first two items in the xml file `

-90.0 -180.0 50.0 1774.13901143

-89.0 -180.0 50.0 1817.12912177 `
bangerth commented 3 years ago

I think in the end the exact format of how the data is presented is not all that important as long as it is documented so that others can put their data in the same format and the function can read it. I will note that you are using a very verbose format because every single entry has much XML around it. It might be useful to think about organizing around different principles, for example presenting one 1d array of lat values, one 1d array of long values, one 1d array of depth values, and one 3d array for each field. You might, for example, want to check out the VTK file format description at https://vtk.org/wp-content/uploads/2015/04/file-formats.pdf -- specifically the "XML File Formats" starting on p. 11, and there the StructuredGrid part. This would have the additional benefit that you could just read the whole model into Paraview/Visit from the same file that ASPECT would read.

paddywball commented 3 years ago

I have reformatted the files as you suggested Wolfgang, but I might just make the file a HDF5 file, since yesterday's email exchanges indicated Timo was looking to use that format for the tomographic models? It makes sense to use that same format for the tomographic models and the temperature models derived from tomographic models.

tjhei commented 3 years ago

exchanges indicated Timo was looking to use that format for the tomographic models?

I am working on a pull request that allows the user to read netcdf files into the StructuredData class as an alternative to the ASCII format. I am not opposed to other formats (for example hdf5 directly without going through netcdf), but I am not a big fan of an xml based format, especially if it is something you invented by yourself.