ornl-cees / datatransferkit Goto Github PK
View Code? Open in Web Editor NEWA library for multiphysics solution transfer. ARCHIVED
Home Page: https://datatransferkit.readthedocs.io/en/dtk-3.0/
License: BSD 3-Clause "New" or "Revised" License
A library for multiphysics solution transfer. ARCHIVED
Home Page: https://datatransferkit.readthedocs.io/en/dtk-3.0/
License: BSD 3-Clause "New" or "Revised" License
The current interface of Entity has
void boundingBox( Teuchos::Tuple<double,6>& bounds ) const;
Should not the the second argument be 2*physicalDimension()? Or is it just this way for simplicity and the last tuple values are simply not used for lower dimensions?
Tpetra::CreateMultivectorFromView using a Teuchos::ArrayRCP has been deprecated. This is used throughout the code to wrap raw data blocks in Tpetra::Multivector objects. Update the API to remove the deprecation warnings and conform with the new API.
Provide a *_inst.cpp file with explicit instantiations for all DTK templates types that have a common set of typical template parameters. Do the same for Tpetra objects. This should dramatically reduce compile times.
So far, completed for: PointCloud/src/ -> EuclideanDistance<int DIM>
Add completed classes as we progress...
An implementation of the IntegralAssemblyMap inside of the new operator interface is needed to recreate that functionality under the new API. This task is complete when it is tested.
Setup a CDash server for testing DTK locally. Link this server to this github repo for continuous/nightly testing of the library.
The map operator factory scheme is not scalable as more operators are added - it becomes very hard to maintain. In addition, it does not follow the open-closed principle as users can not inject their own implementations into the factory. We need to assess our construction scheme and use an abstract builder/factory pattern.
We need a separate repository for exodus files and other data for testing dtk as well as generating examples.
Also look at attachment options.
Remove the current exodus files from the git history.
We would like to be able to define a new partitioning of an entity set to load balance map operator setup and search operations. This includes a concept/API for parallel partitioning of entities and repartitioning.
Develop C/Fortran interfaces to the point cloud operators for future Fortran interface.
Add a way for DTK to query environment variables. This would be useful for making more debug options available at run time, so that users wouldn't have to recompile their release build in order to get some useful debug information.
This is motivated by a recent decision to provide a similar functionality in Tpetra (see trilinos/Trilinos#688). Tpetra or Teuchos could in the future provide the API to query the environment (see trilinos/Trilinos#654).
SupportId type is currently std::size_t
Consider either changing to long long or unsigned long long or template alias at configure time
An implementation of EntityIterator
would be useful for basic containers. These include all standard library types that implement begin, end, size, and who's dereference operator for iterator
or const_iterator
returns an Entity
instance rather than some compound type.
For example:
template<Container>
ContainerIterator<Container>::ContainerIterator( const Teuchos::RCP<Container>& container )
'
with:
assert_same_type<Container::value_type,Entity>::value == true
would permit iterators to be constructed like:
EntityIterator iterator = ContainerIterator<std::vector<Entity> >( std_vector_rcp );
Identical to the normal implementation in #6 we can use finite difference ideas to provide a default implementation of the basis gradient computation.
We need a consistent tolerance nomenclature for the multiple algorithms that require them. For example:
DTK needs a general shared domain and interface L2 projection framework.
Entity and EntitySet now inherit from Teuchos::Describable. Fill in the subclass implementations.
Building DTK using the Libmesh install produced by the MOOSE update_and_rebuild_libmesh.sh script causes the following build error:
DTK_LibmeshEntityIntegrationRule.cpp: In member function ‘virtual void DataTransferKit::LibmeshEntityIntegrationRule::getIntegrationRule(const DataTransferKit::Entity&, int, Teuchos::ArrayTeuchos::Array&, Teuchos::Array&) const’:
DTK_LibmeshEntityIntegrationRule.cpp:65:46: error: conversion from ‘libMesh::UniquePtrlibMesh::QBase {aka std::unique_ptr<libMesh::QBase, std::default_deletelibMesh::QBase >}’ to non-scalar type ‘libMesh::AutoPtrlibMesh::QBase’ requested
static_castlibMesh::Order(order) );
This must be caused by recent addition of the --enable-unique-ptr flag to that build script. Switching it to --disable-unique-ptr fixes the build issue.
Not sure if the fix should just be on the user to switch this flag, just wanted to raise the issue here.
.clang-format
configuration file [S & B]Unit tests and sanity checks for implementations of the core interfaces. An explicit test is needed for the EntityIterator
Need to define sanity checks for: Entity, EntityImpl, EntityLocalMap, EntityShapeFunction, EntityIterator, EntitySet
The source has been refactored so all map operators reside in a single sub package. Add a factory to this sub package for building map operators.
Implement and unit test the ParallelSearch class under the defined interface.
Tests:
Wrap the mesh-free interpolator in the MapOperator interface.
Question: should we blow away the interpolator api and just use the underlying subclasses? Probably not as this hides a lot of templating. We can also roll this information into a larger factor by creating a sublist.
This issue is resolved when we have a working spline and moving least square interpolator underneath the MapOperator interface.
Currently only the consistent interpolation operator can keep missed range DOFS where DTK will put zeros in the solution vector. We have added capability to that map to keep the original solution. We need to propagate this capability and tracking missed range DOFS to all maps. This should be straightforward as this is handled entirely by the parallel search.
RBF interface currently has RadialBasisPolicy::create( radius ) and RadialBasisPolicy::evaluateValue( basis, dist ). We want this to be RadialBasisPolicy::create() and RadialBasisPolicy::evaluateValue( basis, dist, radius ).
Remove global ordinal template on mesh free code in favor of uint64_t
It seems that getEntity() is not being used in any of the operator implementations. We should evaluate if we really need this function and remove it if we don't need it.
Version 2 of the code will be released prior to starting development on version 3. The following needs to be finished:
MapOperator
should become MapOperator<Scalar>
to permit the transfer of data types other than double. There are a large variety of use cases where this is true.
_Question_: Does the shape function infrastructure need to also be templated on this scalar type or can we leave this only at the operator level? For now assume DOFs are of a scalar type and shape function data is double.
To enable L2 projection and other general algorithms we need an integration framework. This should simply be a client API that provides integration rules on an entity-by-entity basis.
There was a previous ticket talking about allowing users to provided ghosted nodes in the PointCloud operators. I discarded this by saying that the algorithm requires local uniqueness to solve the problem. We can let the user give us ghosts and provide a domain and range iterator filter that only operates on nodes that are local.
Implement and test initial ConsistentInterpolationOperator
implementation of MapOperator
. This class will form the basis for finite element interpolation, basic volume-to-volume transfers, and other transfers that rely on simple collocation via basis functions.
Unit Tests:
This issue is blocked and can only be completed when issue #4 is completed.
The SplineInterpolation test fails on my machine but passes on most of the CDash builds. There are CDash builds in which this test passes some nights and not others. The test started failing after Tpetra switched to view semantics as part of the Kokkos refactor. This issue will track the process of finding the bugs. It may be a memory leak.
I had forgotten to clone DTKData and make a soft link in DTK source dir and configure went through without error.
It crashed during build:
make[2]: *** No rule to make target /Users/qdi/Projects/dtk/source/trilinos/11.14.3/DataTransferKit/DTKData/exodus/cube_mesh.exo', needed by
DataTransferKit/packages/Adapters/STKMesh/example/cube_mesh.exo'. Stop.
We probably want to catch that at config time.
The distributor calls in point cloud and the search unroll the coordinates and call the distributor three times. If the data is interleaved we don't need to do this. Fix these calls.
Interface implementations to date have indicated that the most difficult of the interfaces to understand and correctly implement is the EntityIterator interface. We will explore providing a default implementation for user objects in containers that provide standard forward iterators. The user will then just have effectively implement a creation policy which returns a DTK Entity given a user object from the container.
KNN support is needed as an alternative to a fixed radius in the RBF operators. The RBF interface has been updated for this work via issue #38. Work is happening via pull request #52.
The steps are:
Would be nice to have a proper working configuration to share. Once we figure it out, we can add a .ycm_extra_conf.py to $DTK_ROOT.
@dalg24 could you share your partial?
Write an initial implementation of STK mesh interfaces with tests and examples.
All operators should be applicable in transpose mode. We need to expose the hasTransposeApply() interface to all operators to ease in refactoring with first priority being the mesh-free operators.
To start the common refinement integration, Topaz needs to be migrated to the new DTK structure. This issue is satisfied when we have the Topaz capability building and testing as a sub package. We do not need to refactor and wrap the common refinement implementation under the operator interface yet.
The bounding box computations in coarse global search have no tolerance so certain applications were failing to locate valid points where a shared interface is involved. A tolerancing scheme needs to be added to this algorithm. Tests should also be added.
If a user gives multiple points with the same coordinates, rank deficiency will be generated in the linear systems. This will be a common use case when mesh nodes are used for interpolation.
Fix this by building a kD-tree and searching it with itself for identical points. Throw out those points.
The BasicGeometryAdapter sub package contains basic geometric structures and implementations of the core DTK interfaces. These will not only be used by clients with basic needs but also as an implementation for testing the core operator/search interfaces for cases where basic geometries may be used.
Provide implementations and tests.
A default implementation using a finite difference scheme and the current mapping infrastructure in EntityLocalMap
is needed for the function EntityLocalMap::normalAtReferencePoint()
If we are interested in Kanban boards to track issues for DTK, we could try out the new Github Projects boards. Hopefully, they would be faster that the 3rd party waffle app.
We forgot to add an error handling scheme for the C/Fortran APIs. Inside the C implementation we need to wrap C++ code in try/catch blocks and return error codes. The C error codes need to forwarded to the Fortran.
will elaborate on this later
Scripts that we use should be available.
We have to ensure we keep them up-to-date.
Also we should put here any script we use on eos or any other hpc facility.
Setup a doxygen build and populate a gh-pages branch for online documentation
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.