hyteg merge requestshttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests2024-07-16T10:11:08+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/784Implement fix for updating viscosity profile data2024-07-16T10:11:08+02:00Eugenio D'AscoliImplement fix for updating viscosity profile dataIf a custom viscosity profile is provided the re-dimensionalisation is done using the
minimum viscosity as new reference viscosity to ensure the non-dimensional minimum viscosity is
equal to 1.
Previously, updating the reference viscosit...If a custom viscosity profile is provided the re-dimensionalisation is done using the
minimum viscosity as new reference viscosity to ensure the non-dimensional minimum viscosity is
equal to 1.
Previously, updating the reference viscosity was performed after the first initial solution step which
could result in a non-dimensional viscosity value below 1.
This has been fixed and now a minimum non-dimensional viscosity of 1 will be ensured during runtime.
Addtionally, the function udpateRefViscosity() was renamed to updateViscosity() for improved readability and
the viscosity profile log will output the viscosity in SI unit (Pa s).
Also, if a viscosity profile is provided and the element to interpolate the viscosity onto lies between
two data points from the viscosity profile a linear interpolation is performed to estimate the viscosity of the element at the given radius.
This linear interpolation is improved by looping over the profile with a "while" loop.Eugenio D'AscoliEugenio D'Ascolihttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/781Writing single value attributes to adios2 output2024-07-16T17:45:05+02:00Roman FreisslerWriting single value attributes to adios2 outputThis adds functions for writing (almost) any single value attributes to adios2 output with the AdiosWriter under src/hyteg/dataexport/ADIOS2. Valid data types are defined in "adiosHelpers::adiostype_t". Having these attributes available ...This adds functions for writing (almost) any single value attributes to adios2 output with the AdiosWriter under src/hyteg/dataexport/ADIOS2. Valid data types are defined in "adiosHelpers::adiostype_t". Having these attributes available could be handy for post-processing and analysis, as well as for checkpointing. I also added a non-exhaustive selection of attributes to be written to both the P1- and P2-output in the TerraNeo app.https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/775Some minor updates to the TerraNeo app README.2024-06-24T21:25:43+02:00Nils KohlSome minor updates to the TerraNeo app README.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/769Add Uzawa solver for TN-app2024-06-18T08:16:13+02:00Ponsuganth Ilangovan Ponkumar IlangoAdd Uzawa solver for TN-appIn relation to #243 this adds the Uzawa solver with projection from an old branch.
This should be the last MR before merging the TerraNeo-App;In relation to #243 this adds the Uzawa solver with projection from an old branch.
This should be the last MR before merging the TerraNeo-App;Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/768Make RadialProfileTool compatible for variable mesh widths2024-06-18T10:34:46+02:00Ponsuganth Ilangovan Ponkumar IlangoMake RadialProfileTool compatible for variable mesh widthsThis is in relation to #243 and #259
Basically adds the computation needed for the Radial profile utility functions to accommodate a general structure of radial mesh layers `std::vector<real_t>` which is supported by `meshSphericalShell`This is in relation to #243 and #259
Basically adds the computation needed for the Radial profile utility functions to accommodate a general structure of radial mesh layers `std::vector<real_t>` which is supported by `meshSphericalShell`Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/765Add the first version of TerraNeo app2024-06-19T11:08:15+02:00Ponsuganth Ilangovan Ponkumar IlangoAdd the first version of TerraNeo appThis is to mainly add the first version of the TerraNeo app in relation to #243
The solvers !755 !769 and the operators !757 needed for the app are already in master. We (@dascoli) currently have a _working_ version which we want to tes...This is to mainly add the first version of the TerraNeo app in relation to #243
The solvers !755 !769 and the operators !757 needed for the app are already in master. We (@dascoli) currently have a _working_ version which we want to test and resolve some issues (for example #259) before merge, hence 'draft' status for now.
Minor things to be done,
- Improve readme and logging
- FE functions `std::map` (pending from #243)
- Add/remove useful/less parameters
One extra operator from the `src/terraneo/operators` would be the `P2TransportRHSOperator` which is currently split but not yet fully used in the app.
PS: I am just helping in finishing the MR, the app is a joint effort of lot of other major contributors, see copyrights.Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/763[Rebased !759] Radial shell output, radial shell IDs, duplicate DoF counting2024-06-12T20:52:42+02:00Nils Kohl[Rebased !759] Radial shell output, radial shell IDs, duplicate DoF countingRebasing !759 once more.Rebasing !759 once more.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/762Continuous checkpointing with ADIOS22024-06-14T20:29:19+02:00Ponsuganth Ilangovan Ponkumar IlangoContinuous checkpointing with ADIOS2This modifies the checkpoint class and adds/modifies the member functions so that it supports checkpointing the same FE function multiple times in adios step episodes.
Data exported,
- TIME variable
- FE functions $\times$ Number of tim...This modifies the checkpoint class and adds/modifies the member functions so that it supports checkpointing the same FE function multiple times in adios step episodes.
Data exported,
- TIME variable
- FE functions $\times$ Number of timesteps
- TimestepInfo - vector of time values
While importing, the `AdiosCheckpointImporter` reads the `TimestepInfo` and can then be used to read the FE function value at any timestep. An extra variable is sent to the `restoreFunction` to choose the timestep.Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/759Radial shell output, radial shell IDs, duplicate DoF counting2024-06-12T20:52:44+02:00Nils KohlRadial shell output, radial shell IDs, duplicate DoF countingRebased and extended from !753.
# Content
This MR deals with radial output and some other features.
Contributions:
- fixes and refactoring of the computation of radial shells and layers for the refined, radially equidistant Icosahedr...Rebased and extended from !753.
# Content
This MR deals with radial output and some other features.
Contributions:
- fixes and refactoring of the computation of radial shells and layers for the refined, radially equidistant IcosahedralShellMesh
- a new class `RadialShellData` to gather and store the FE data in radial layers without connectivity
- VTK output for point clouds (general point clouds, not limited to the radially organized data above) via `VTKPointCloudOutput`
- a helper function to interpolate the radial shell ID to FE functions (can be used to filter radial shells in post-processing)
- a helper function to interpolate the number of duplicated nodes in the VTK/ADIOS output (currently all data including ghost-nodes is written for each macro-volume - this creates duplicates - they can be detected/filtered with this additional data)
# Note on layers vs shells
There are some issues regarding the nomenclature of *shell* and *layer*. It appears that their definition is unclear. We need to distinguish between
- (what I currently call *shell*) 2D manifolds in 3D space, i.e., the boundaries of a sphere (centered at the origin) with a specific radius, and
- (what I currently call *layer*) 3D volumes that have two such manifolds as boundaries.
Unfortunately, these definitions are not used consistently, especially in older code and documentation (see e.g. documentation of the MeshInfo).
# Plots of the point cloud output
Example 1: all shells selected:
![point_cloud_vtk_01](/uploads/defc4e40d2eaf083c26d2478ec2cfd74/point_cloud_vtk_01.png)
Example 2: only two selected shells:
![point_cloud_vtk_02](/uploads/0d6dd3ac87d1aeee10eb25e740050fc0/point_cloud_vtk_02.png)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/757Add full energy operator for TN-app2024-06-13T10:13:17+02:00Ponsuganth Ilangovan Ponkumar IlangoAdd full energy operator for TN-appThis is in relation to #243
Adds the full energy operator, currently kept under [`src/terraneo/operators`](https://i10git.cs.fau.de/hyteg/hyteg/-/tree/ponsuganth/tn-energy-operator/src/terraneo/operators). There are no tests currently ...This is in relation to #243
Adds the full energy operator, currently kept under [`src/terraneo/operators`](https://i10git.cs.fau.de/hyteg/hyteg/-/tree/ponsuganth/tn-energy-operator/src/terraneo/operators). There are no tests currently but the operator is included in the solver test so that at least compilation is checked in the pipeline for now. Later we will add apps and tutorials using this.
Any suggestions on naming, namespaces and folder structure would be helpful.Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/755Adding Stokes operator wrappers and solvers for TN app2024-06-13T10:13:17+02:00Ponsuganth Ilangovan Ponkumar IlangoAdding Stokes operator wrappers and solvers for TN appThis is in relation to #243
As we need some working solver with freeslip, I made a solver template heavily based on Andi's implementation, with freeslip projection operators. To note that this is still a temporary solution for the free...This is in relation to #243
As we need some working solver with freeslip, I made a solver template heavily based on Andi's implementation, with freeslip projection operators. To note that this is still a temporary solution for the freeslip, I have added the solvertemplate in to `namespace temporary`.
The Stokes operator wrappers are in [_terraneo_](https://i10git.cs.fau.de/hyteg/hyteg/-/tree/ponsuganth/stokes-fs-ops-solvers/src/terraneo/operators) but solvers are under [_hyteg_](https://i10git.cs.fau.de/hyteg/hyteg/-/tree/ponsuganth/stokes-fs-ops-solvers/src/hyteg/solvers/solvertemplates)
A test is also added but is currently not activated as it might take a long time in CI.Ponsuganth Ilangovan Ponkumar IlangoPonsuganth Ilangovan Ponkumar Ilangohttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/753Draft: Radial shell output2024-06-07T17:32:23+02:00Nils KohlDraft: Radial shell outputThis MR implements output of FE coefficients (P1 and P2, scalar and vector-valued) to point clouds that are organized in radial shells for the thick spherical shell mesh (with blending).
The scope is as follows:
- [x] a new class `Radia...This MR implements output of FE coefficients (P1 and P2, scalar and vector-valued) to point clouds that are organized in radial shells for the thick spherical shell mesh (with blending).
The scope is as follows:
- [x] a new class `RadialShellData` to gather and store the FE data in radial layers
- [x] VTK output for point clouds (general point clouds - including those generated above) via `VTKPointCloudOutput`
- [ ] test P2 since edge DoFs and shells must somehow be organized meaningfully
- [ ] ~~ADIOS2 output (requires ADIOS2 consulting from @mohr)~~
It hopefully will also resolve issues regarding the nomenclature of *shell* and *layer* as well as corresponding computations. It appears that their definition is unclear. We need to distinguish between
- (what I currently call *shell*) 2D manifolds in 3D space, i.e., the boundaries of a sphere (centered at the origin) with a specific radius, and
- (what I currently call *layer*) 3D volumes that have two such manifolds as boundaries.
Unfortunately, these definitions are not used consistently, even in older code and documentation.
-----
VTK seems to work already for P1:
Example 1: all shells selected:
![point_cloud_vtk_01](/uploads/defc4e40d2eaf083c26d2478ec2cfd74/point_cloud_vtk_01.png)
Example 2: only two selected shells:
![point_cloud_vtk_02](/uploads/0d6dd3ac87d1aeee10eb25e740050fc0/point_cloud_vtk_02.png)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/732TerraNeo - parameter handling, initialization, radial profiles2024-04-18T12:24:53+02:00Nils KohlTerraNeo - parameter handling, initialization, radial profilesThis MR is a continuation of !712 (and !707 which is a subset of !712).
The MR rebases and refactors what has been implemented in !712.
Introduces:
* parameter handling for the TN app
* radial profile computation
* IO for radial profil...This MR is a continuation of !712 (and !707 which is a subset of !712).
The MR rebases and refactors what has been implemented in !712.
Introduces:
* parameter handling for the TN app
* radial profile computation
* IO for radial profiles
* temperature initialization functions
Major edits compared to !712:
* refactored temperature initialization functions (now just a "library" of functions that create lambdas for `interpolate()`)
* refactored the radial profile tool (much more efficient as all relevant values are computed in a single loop, [free your functions](https://github.com/CppCon/CppCon2017/blob/master/Presentations/Free%20Your%20Functions/Free%20Your%20Functions%20-%20Klaus%20Iglberger%20-%20CppCon%202017.pdf))
* refactored parameter IO (using json with better error handling, no more global variables, etc.)Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/724Add viscosity profiles to data/viscosityProfiles directory2024-06-14T17:07:14+02:00Eugenio D'AscoliAdd viscosity profiles to data/viscosityProfiles directoryViscosity profile files in `.json` format as background viscosity for simulation runs with temperature dependent viscosity are
stored in `/data/terraneo/viscosityProfiles/`.
Two profiles are provided (`ViscosityProfile_Stotz_et_al_2017...Viscosity profile files in `.json` format as background viscosity for simulation runs with temperature dependent viscosity are
stored in `/data/terraneo/viscosityProfiles/`.
Two profiles are provided (`ViscosityProfile_Stotz_et_al_2017.json` and `ViscosityProfile_Lin_et_al_2022.json`).
The README.md file will contain a detailed description of the two profiles and additional references for a profound
knowledge about the viscosity profiles.Eugenio D'AscoliEugenio D'Ascolihttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/712Draft: Adding tool for parameter file handling2024-03-27T15:05:16+01:00Eugenio D'AscoliDraft: Adding tool for parameter file handlingFor the handling of parsing, printing and storing relevant parameterisations and corresponding data (e.g. background viscosity profiles) a new tool "ParameterTool.hpp" is available within the src/terraneo/helpers directory.
TerraNeo's u...For the handling of parsing, printing and storing relevant parameterisations and corresponding data (e.g. background viscosity profiles) a new tool "ParameterTool.hpp" is available within the src/terraneo/helpers directory.
TerraNeo's utilised data structures will be available within the directory src/terraneo/helpers in "TerraNeoDataStructures.hpp".
Implementation of the parameter tool allows users to parse and log the parameters file content and provides the possibility to
load and store background profile data (i.e. background viscosity profile). The background profile can be handed over in .json
format or as .txt/.csv file.
With one column containing the depth/radius [km] and the second column containing the physical quantity of interest in SI units.
This should allow us to modularise parameter data handling within convection apps and lets us stay closer to master according to issue #243 .Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/707Draft: Adding tool for temperature initialisation2024-03-27T15:05:44+01:00Eugenio D'AscoliDraft: Adding tool for temperature initialisationFor the temperature initialisation a new tool "InitialisationTool.hpp" is now
available within the src/terraneo/helpers directory. Temperature initialisation is
performed superimposing a distinct amount of white noise or temperature devi...For the temperature initialisation a new tool "InitialisationTool.hpp" is now
available within the src/terraneo/helpers directory. Temperature initialisation is
performed superimposing a distinct amount of white noise or temperature deviations from spherical harmonics onto the reference
temperature profile (currently adiabatic profile). This should allow us to modularise initialisation procedures in convection apps and
lets us stay closer to master according to issue #243 .Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/632Draft: Convection Model Operators, SUPG Stabilisation Operators, Elementwise DoFValueOperators (+Tests), Second derivatives for the Blending Maps, PETScHDF5 ...2024-02-21T17:05:49+01:00Andreas BurkhartDraft: Convection Model Operators, SUPG Stabilisation Operators, Elementwise DoFValueOperators (+Tests), Second derivatives for the Blending Maps, PETScHDF5 Function Saving, Projection subclasses for Smoothers and Restriction/Prolongation**Preface: Our pipeline seems to be broken right now, so we should probably wait until it works again.**
This merge request contains several new operators and features aimed at the TerraNeo application.
A few comments on the content o...**Preface: Our pipeline seems to be broken right now, so we should probably wait until it works again.**
This merge request contains several new operators and features aimed at the TerraNeo application.
A few comments on the content of the various diffs:
**composites/P2P1TaylorHoodCompStokesOperator.hpp:** Implements a P2P1 Block Operator for the compressible Stokes (both ALA and TALA are available) with potentially temperature dependent viscosity. It can also generate an appropriate right hand side. You can also activate or deactivate the frozen velocity approach (i.e. if the compressible term in the mass conservation equation is made explicit).
LHS velocity:
$$2 \int_{\Omega} \eta(x,T) \sigma(u) : \sigma(v) \text{ } dx - \frac{2}{\text{dim}} \int_{\Omega}{\eta(x,T) (\nabla \cdot u) \cdot (\nabla \cdot v)} \text{ } dx - \int_{\Omega} \text{div}(v)p_d \text{ } dx - \int_\Omega \frac{\text{Di}}{\Gamma_0} \rho(x) (K_T)^{-1} p_d g \cdot v \text{ } dx$$
RHS velocity:
$$-\int_\Omega \frac{\text{Ra}}{\text{Pe}} \rho(x) \alpha T_d g \cdot v \text{ } dx$$
LHS pressure (here without frozen velocity):
$$ -\int_\Omega \left (\frac{\nabla \rho(x)}{\rho(x)} \cdot u \right ) q \text{ } dx - \int_\Omega (\nabla \cdot u) q \text{ } dx$$
RHS pressure: 0
**src/p2functionspace/P2CompTransportOperator.hpp:** Implements a P2 Operator for the time (in-)dependent energy conservation equation with optional SUPG Stabilisation. Various time stepping schemes (implicit Euler, BDF2, Crank-Nicolson) are available (some additional function calls from outside might be required, e.g. the operator provides a method to save the previous time step right hand side for crank nicolson). Can also be used for the diffusion solve step when using the MMOC operator splitting approach. It can also generate an appropriate right hand side.
LHS temperature (here for the adiabatic heat on the lhs, but can be also be made explicit):
$$ \int_\Omega \frac{\partial T}{\partial t} w \text{ } dx + \int_\Omega (u \cdot \nabla T) w \text{ } dx + \int_\Omega \frac{k }{\text{Pe} \text{ } C_p}\nabla T \cdot \nabla \left ( \frac{w}{\rho(x)} \right ) \text{ } dx - \int_\Omega \text{Di} \text{ } \frac{\alpha}{C_p} T (u \cdot g )w \text{ } dx + \text{SUPG Terms (if used)}$$
RHS temperature:
$$ - \int_\Omega \frac{1}{C_p} H w \text{ } dx -\int_\Omega \frac{\text{Pe}}{\rho(x) C_p}\frac{\text{Di}}{\text{Ra}} \left (\tau\left (u,\eta\left (x,T \right )\right ) : {\varepsilon(u)}\right ) w \text{ } dx + \text{SUPG Terms (if used)}$$
The lhs and rhs above are consequently also dependent on the chosen time discretisation.
**src/hyteg/p2functionspace/P2FullViscousTDependentOperator.hpp, src/hyteg/p2functionspace/P2GradRhoRho_P2_Operator.hpp, src/hyteg/p2functionspace/P2ScaledMassDiffusionOperator.hpp, src/hyteg/p2functionspace/P2VariableBlendingKMassScalarToVectorOperator.hpp, src/hyteg/gridtransferoperators/P2toP1GradRhoRho_P2_Operator.hpp, src/hyteg/gridtransferoperators/P1toP2VariableBlendingKMassScalarToVectorOperator.hpp:** Various operators that conveniently combine the usage of multiple other operators (e.g. if we apply one on every component).
**src/elementwiseoperators:** Added all combinations of P1/P2 ElementwiseDoFValueOperator classes. These operators can be inherited from and provide a way (via the DoFValues_ vector) to access the DoFs of another FEM function during the evaluation of a form. This allows us for the creation of operators like an advection operator that takes a velocity field as an additional input.
Added a setConstantScaling function to all elementwise operators. This can be used to scale your operators by a constant on the fly (without having to create for example a linear combination form).
There are some bug fixes and the ability to use a custom form for P2ToP1 and P1ToP2 elementwise operators included.
**src/elementwiseoperators/generated:** Folder containing all of the generated ElementwiseDoFValueOperators. In particular it adds operators for adiabatic heating, advection, diffusion (only supg), temperature dep. stokes, the grad(rho)/rho * u compressible term in the mass conservation equation, div_k_grad scaled by rho^-1, mass(only supg), shear heat and respective SUPG Stabilisation terms.
**src/p1functionspace/VertexDoFFunction, src/edgedofspace/EdgeDoFFunction, src/functions/DoFValueFunctions:** Added a DoFValueFunction class that both VertexDoFFunction and EdgeDoFFunction inherit from. No previous functionality of VertexDoFFunction and EdgeDoFFunction was changed, I just implemented the additional functions defined in the DoFValueFunction base class. The defined functions are required for the DoFValueOperators to work.
**src/hyteg/composites/VelocityOperator_T_Wrapper, src/hyteg/solvers/SubstituteSolver.hpp:** Some convenient wrappers, allowing you to wrap a operator with a different VelocityOperator_T type and to use a solver for a different operator type (e.g. if you want to solve Laplace as a preconditioner, but the preconditioner is expected to be a solver for a different operator).
**src/petsc/PETScHDF5FunctionSave.hpp:** Functions that allow you to save functions and paramters via creating a PETSc Vector and saving it in parallel to a binary file via HDF5. Has some limitations since you can only reload your functions in the same configuration as you saved it.
**src/solvers/preconditioners/stokes:** Two preconditioner classes used for benchmarks and the convection model
**src/solvers/solvertemplates/StokesSolverTemplates.hpp:** Pulled over some changes to the StokesSolverTemplates solver used in the other Terraneo branches. No functionality is changed but you can now distinguish between absolute and relative tolerance.
**src/solvers/ChebyshevSmoother.hpp:** Added a subclass of the Chebyshev Smoother that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**src/solvers/GMRESSolver.hpp:** Serveral bug fixes and additional functions from Andreas Wagner to the GMRES solver which we found during our testing of the GMRES.
**src/solvers/MinResSolver.hpp:** Pulled over some changes to the MinRes solver used in the other Terraneo branches. No functionality is changed but you can now define an absolute tolerance.
**src/solvers/UzawaSmoother.hpp, /src/hyteg/composites/P2P1UzawaDampingFactorEstimationOperator.hpp:** Added functions for the estimation of the Uzawa Omega paramter also in case of the P2CompStokesOperator and added a subclass of the UzawaSmoother that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**src/hyteg/gridtransferoperators/P2P1StokesToP2P1StokesProlongation.hpp, src/hyteg/gridtransferoperators/P2P1StokesToP2P1StokesRestriction.hpp:** Restriction and Prolongation operator subclasses that contains a normal projection at an appropriate spot for the freeslip boundary conditions.
**data/meshes:** Just some additional meshes which are offset from the origin (are used for testing with the sphericalCoordinateMap blending map.
**src/forms:** Just some additional generated blending forms.
**src/geometry:** Added second derivative functions (needed for SUPG Stabilisiation) for all blending maps and a new spherical coordinate map.
**tests/hyteg/operators:** Added tests checking if the various DoFValueOperators are calculating the correct integrals and if the diagonal calculation for the temperature dependent stokes works.
Hopefully I haven't forgotten anything and these are all changes.Andreas BurkhartAndreas Burkharthttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/563Upgrade algorithm for finding plate associated with point2023-01-24T21:07:01+01:00Marcus MohrUpgrade algorithm for finding plate associated with pointThis merge request is superseding !560, as gitlab does, unfortunately, not allow to exchange the underlying branch of a merge request.This merge request is superseding !560, as gitlab does, unfortunately, not allow to exchange the underlying branch of a merge request.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/560Upgrade in the plates module in assigning plates to points2023-01-24T16:13:26+01:00Berta VilacĂsUpgrade in the plates module in assigning plates to pointsThe function point-in-polygon that finds which plate belongs the point has been upgraded.
Now, it uses the coordinates lon, lat and places the point and the polygon at the surface of a sphere using the boost library. It also calculates ...The function point-in-polygon that finds which plate belongs the point has been upgraded.
Now, it uses the coordinates lon, lat and places the point and the polygon at the surface of a sphere using the boost library. It also calculates the distance from the point to the polygon using the functionalities of the boost library.
Each point has a unique solution to the polygon that belongs to.
Also we generalised plates, such as, internally it does the conversion from xyz to lon lat coordinate system, allowing the user to pass in any xyz point in any radius.
The dependency of plates to CGAL has been removed and such the cmake files have been modified.
(commits 1a46caad50806b576b2fb1d63f2efe8a32ab5015, 0c7ed8c551c039a006aa366355edc7edbe66d72a and 244525a91244f11250b68ead35ea1abf27696a63)https://i10git.cs.fau.de/hyteg/hyteg/-/merge_requests/542Fix bugs in PlateVelocityProvider2022-11-17T16:47:00+01:00Marcus MohrFix bugs in PlateVelocityProviderMarcus MohrMarcus Mohr