Addition of an unstructured lookup class #3128
Conversation
include/aspect/utilities.h
Outdated
| * needs to contain the number of columns and lines in the file: | ||
| * '#POINTS: TOTALNUMBERDATALINES NUMBERCOORDCOLUMNS NUMBERDATACOLUMNS'. | ||
| * For example '# POINTS: 5 4 3' would be 5 lines of data, 4 columns of coordinates, | ||
| * and 3 columns of data. The comments can optionally be followed by a |
There was a problem hiding this comment.
could you align the stars here?
| * single line, which does not start with '#', containing the names of | ||
| * the data columns. | ||
| * The order of the following data columns has to be | ||
| * 'coordinates data' with @p querydim coordinate columns and @p components |
There was a problem hiding this comment.
so x,y,z,c1,c2,...? And should guerydim be dim?
include/aspect/utilities.h
Outdated
| public: | ||
|
|
||
| /** | ||
| * The following variables are properties of the material files |
There was a problem hiding this comment.
What do you mean with material files?
include/aspect/utilities.h
Outdated
|
|
||
| virtual void initialize (const MPI_Comm &comm, | ||
| std::string datadirectory, | ||
| std::vector<std::string> material_file_names); |
There was a problem hiding this comment.
same, what do you mean with material?
include/aspect/utilities.h
Outdated
|
|
||
|
|
||
| /** | ||
| * Returns the data (velocity, temperature, etc. - according |
include/aspect/utilities.h
Outdated
| /** | ||
| * Returns the data (velocity, temperature, etc. - according | ||
| * to the used plugin) for the n closest points to the target point. | ||
| * The function returns a vector of pairs of < data_return , Euclidean distance >, |
|
Addressed comments |
| * The order of the following data columns has to be | ||
| * 'coordinates data' with @p querydim coordinate columns and @p components | ||
| * data columns. @p querydim and @p components need to | ||
| * match NUMBERCOORDCOLUMNS NUMBERDATACOLUMNS, respectivily. |
There was a problem hiding this comment.
| * match NUMBERCOORDCOLUMNS NUMBERDATACOLUMNS, respectivily. | |
| * match NUMBERCOORDCOLUMNS and NUMBERDATACOLUMNS, respectively. |
|
|
||
|
|
||
| // Create an instance of a kdtree object as a member variable of the class | ||
| KDTree<querydim> coordinate_kdtree; |
There was a problem hiding this comment.
dealii::RTree<std::size_t, boost::geometry::index::linear<16>, dealii::IndexableGetterFromIndices<std::vector>>
|
|
||
|
|
||
| virtual void initialize (const MPI_Comm &comm, | ||
| std::string datadirectory, |
There was a problem hiding this comment.
| std::string datadirectory, | |
| const std::string &datadirectory, |
|
|
||
| virtual void initialize (const MPI_Comm &comm, | ||
| std::string datadirectory, | ||
| std::vector<std::string> file_name_list); |
There was a problem hiding this comment.
| std::vector<std::string> file_name_list); | |
| const std::vector<std::string> &file_name_list); |
| * and instead reading them from the input file allows for more | ||
| * flexible files. | ||
| */ | ||
| UnstructuredDataLookup(const unsigned int components); |
There was a problem hiding this comment.
| UnstructuredDataLookup(const unsigned int components); | |
| explicit UnstructuredDataLookup(const unsigned int components); |
| * data file it is checked that the length of this list is consistent | ||
| * with this number of components. This constructor is mostly provided | ||
| * for backwards compatibility. Not prescribing the number of components | ||
| * and instead reading them from the input file allows for more |
There was a problem hiding this comment.
Do we need this constructor? I think the same one in AsciiDataLookup is only there for backwards compatibility.
There was a problem hiding this comment.
I don't know. Perhaps I can try with and without this constructor in the unit_test, and decide from there.
| * must have three compnents: | ||
| * TOTAL_NUMBER_DATA_LINES NUMBER_COORD_COLUMNS NUMBER_DATA_COLUMNS. | ||
| */ | ||
| std::vector<int> point_dimensions; |
There was a problem hiding this comment.
this might not be necessary to store as a member but a local variable might be enough, right?
| * are from the target point. | ||
| */ | ||
| std::vector< std::pair<std::vector<double>, double> > | ||
| get_data (const Point<querydim> &target_point, const unsigned int n_points) const; |
There was a problem hiding this comment.
I think it would be great to have a second function that only returns the closest point to make the return value simpler.
| get_data (const Point<querydim> &target_point, const unsigned int n_points) const; | ||
|
|
||
| /** | ||
| * Returns a vector that contains the names of all data columns in the |
There was a problem hiding this comment.
| * Returns a vector that contains the names of all data columns in the | |
| * Return a vector that contains the names of all data columns in the |
|
Can you add a unit test similar to the one you showed us a couple of days ago? |
| } | ||
|
|
||
| // Set the coordinate points into the kdtree object | ||
| coordinate_kdtree.set_points (coordinate_values); |
There was a problem hiding this comment.
kdtree=pack_rtree_of_indices(const ContainerType &container);
Follow-up for #3126. I added a new class to read in unstructured data tables. The class is modeled off of the ASCII data reader. The purpose in mind was to read in multiple unstructured material properties files, but this new class is not restricted to this purpose. The data files should contain columns of coordinates, and columns of data. The coordinates are stored in a searchable kdtree object, and the data are stored in vectors. The user can query the n-nearest neighbor data points from a target point. When applied to material properties, this allows the ability to update compositional properties on-the-fly based on current pressure and temperature conditions.