ornl-cees / datatransferkit Goto Github PK

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.

• Define Fortran/C compilers and systems to be used for the work
• Define algorithm input options
• Define algorithm input and output data
• Design C interface using input and output parameters
• Design Fortran interface to interoperate with C interface
• Review Fortran interface with ANL/LLNL code teams
• Implement point cloud operators under C interface
• Test C interface to operators
• Implement the C interface under the Fortran interface
• Test the Fortran interface to operators

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:

1. Point inclusion in reference cell
2. Newton solver
3. Safeguard checks
4. Common-refinement - numerous checks

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.

• Choose clang-format version and define a .clang-formatconfiguration file [S & B]
• Enforce the new format [D]
• Coding style guidelines [S]

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:

1. Search the domain entities with their centroids and ensure the CrsGraph gives the pattern for the identity matrix (search the domain with itself).
2. Axis aligned mesh with random points
3. Rotated and translated axis aligned mesh with random points

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 ).

• Refactor RadialBasisPolicy interface to pass the radius as an evaluation argument
• Update basis function implementations and tstRadialBasis.cpp so tests pass
• Propagate basis function interface changes through point cloud operators. Use the radius from the parameter list for now
• Ensure all point cloud operator test pass

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.

• Evaluate current operator implementations to see if we use getEntity anywhere
• Consider any future operator implementations that might want this functionality
• If we decide we don't need it, remove it from the interface and client implementations

Version 2 of the code will be released prior to starting development on version 3. The following needs to be finished:

• Merge all open pull requests
• Create version 2 branch @Rombur
• Create a new website @Rombur @dalg24
• Publish version 2 documentation and development version on the new website @Rombur
• Make clear in documentation and on front page README that the version 2 branch is a stable release and the master branch is for development and is subject to changing interfaces and data structures. @Rombur @sslattery
• Update the front page README to link to the stable version and add link to the tarball @Rombur ur
• Add version 2 to CI build system for any changes to branch and pull requests/bug fixes @dalg24
• Create announce mailing list
• Announcement of version 2 release

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:

1. Pure finite element interpolation on position function
2. Volume averaged basis with geometry->geometry transfer
3. Domain->Range and Range->Domain mapping

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 byDataTransferKit/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:

• Expose a KNN vs. fixed radius option in the search parameter list.
• Hook into KNN search option. For now will search for KNN+1 to calculate a radius. If were to use KNN to calculate the distance then we would not get a contribution from the farthest point in the support group.
• Update the usage of the RBFs in the operators to either use the fixed radius or to calculate the radius on the fly. The calculated radius will be the euclidean distance between the point of interest and the KNN+1 neighbor.
• Ensure point cloud operator unit tests are passing.

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?

• remove trailing whitespace [A]
• replace tabs by whitespace [A]
• enforce new commits won't introduce new ones [D]

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.

• Make hasTransposeApply() a virtual function or call an equivalent pure virtual implementation in subclasses.
• Propagate hasTranposeApply interface to subclasses and add checks to applyImpl() in subclasses that ensure an appropriate transpose mode has been selected
• Ensure all point cloud operators can operate in transpose mode.

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