Enable parsing of 1D column data and interpolation in functional space using LookupTable object - #401
Conversation
The CSV constructor of LookupTable now accepts an optional readColumns argument. When it is set to true (1D tables only), xinHost is read from the first column of the ASCII file and dataHost from its second column, instead of the first and second lines of the file. Both are then shared on the device as before. The default behaviour (arrays read as lines) and the parsing of 2D tables are left unchanged. Also document the handling of comments and blank lines in CSV files, and add a test of the new column layout in test/utils/lookupTable.
GetNeighbours and GetNeighboursIndx (and their Host counterparts) return the elements of the table surrounding the requested coordinates: the two coordinates bracketing the input along each dimension, the data on the 2^nDim vertices of the surrounding cell, and the corresponding indices in the table. When the table is interpolated in function space, the returned coordinates and data are transformed back with invFunc, so that they are expressed in the original space of the table. Get is left unchanged, and the neighbour search is shared by the new methods through the GetIndices and GetDataIndex helpers.
Get (and GetHost) now accept a LookupTableNeighbours structure in which they store the search they performed. Giving that same structure to GetNeighbours or GetNeighboursIndx makes them reuse this search instead of walking the table a second time, and they search it again as usual as soon as different coordinates are requested. The structure is held by the caller rather than by the lookup table, so that it is thread-private when it is declared inside an idefix_for: a lookup table is shared by all of the threads of a loop, and can hence not cache anything itself. The existing Get is left untouched.
GetNeighbours and GetNeighboursIndx already search the table when they are given a structure which does not hold the requested coordinates yet, and Get reuses whatever search that structure holds, so the two orders are equivalent. Add the tests which check it, on the host and on the device, and document that the order of the calls is irrelevant.
|
@dutta-alankar : let us know when this PR is ready to go through the workflow, as we have a limited workflow capacity, and we can't possibly test each commit you're pushing. |
|
@glesur I'm terribly sorry for the trouble. I think now this is finalized and ready and good to go. |
|
I’ve read your PR in details. While I understand the motivation for supporting specific 1D input, I’m not entirely convinced about the necessity of including the log/exp interpolator in the core codebase. In practice, if logarithmic interpolation is needed, users could simply provide a pre-computed log-scaled table and use the existing LookupTable class to interpolate, followed by any additional processing. This seems like functionality that could remain on the user side rather than being integrated into the main trunk. Additionally, I’m curious about the intended use case for |
@glesur Thanks a lot for having a look at the PR. Let me expand on a few points to give better context for the choices I made. Column-format input. Most standard radiative cooling tables (typically Cloudy-generated) used by codes such as the Athena variants, PLUTO, Quokka, FLASH, and AMRVAC are distributed in column format. Being able to parse Log/exp interpolation. Broken power laws are a very common way to approximate cooling functions in the literature, and linear interpolation in log space naturally reproduces a power law between successive data points. A user could of course supply a pre-transformed table to
|
2 participants
This PR is in preparation of using Tabulated optically thin radiative cooling on Idefix.$\Lambda$ at the tabulated temperature value.
It is common in many codes to use cooling function where the first column is temperature in Kelvin and second is the cooling function
In order to parse data of this type, I extended the functionality of
LookupTablein 1D mode. In addition to this, power law interpolation is also very common, which corresponds to linear interpolation in log space. To achieve this, I introduced toLookupTable::Getfunction the ability to use linear interpolation in function space (usable from both host and device in all dimensions).log/exppair is the default functional space combination with the possibility to have custom functional space (example intest/utils/lookupTable).I ensured that
LookupTableadheres to the original behavior as default to ensure that any previous usage of this utility is not broken.