On Thu, 17 Jan 2013, Derek Gaston wrote:
The way that it works is that each code feeds DTK its mesh (nodes,
elements and connectivity). DTK then creates a "union" mesh out of
all of the meshes of all of the coupled codes.
This is the right way to do things in general, but the details get
*real* tricky - does the union mesh end up being made of
nearly-arbitrary polyhedra when the input meshes aren't aligned?
It then uses this union mesh to push and pull fields from all the
coupled codes. This all works in parallel... and handles the case
where two different codes are using two different parallel
decompositions.
Apparently they are indeed good at tricky details!
So here's what I'm proposing to do at the libMesh level:
1. Create the mesh translator that will take a Mesh and output a DTK mesh.
2. Allow any System to provide a field to DTK
3. Allow any System to accept a field from DTK
Since libMesh understands our fields at a basic level, I believe I can grow
something very
generic at the libMesh level that will work for most libMesh based codes.
I'd want to keep it pretty modular (e.g. ideally System shouldn't need
to know about DTK any more than it knows about Exodus) but I'd love to
see the support get in at the libMesh level.
---
Roy
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
