• Registered: 26-07-2012
  • Posts: 7

Topic: Domain Decomposition w/ multiple time steps

Hello fellow developers,

I recently learned about OOFEM via google and am very excited to learn and use this solver.

I am a graduate student at the George Washington University and am currently working on multiple grid and multiple time-scale (MGMT) simulations in continuum mechanics.

What is MGMT?
> Using MGMT one can selectively discretize different regions of a domain, both in space and time, and still obtain a global, synchronous solution of the entire problem.
Basically, allow different mesh size in distinct regions of a domain and integrate these regions with different time-steps, independent of each other.

My question
> I am really looking forward to implement my formulation using an established FEM solver (such as oofem) that allows user programming capabilities. I would like to know if OOFEM is flexible enough in allowing user to access the core data structure, the solver and the data itself.   

I would really appreciate if the community could share their experience in programming/modifying OOFEM to suit their own applications. Any resources/examples/opinions are much appreciated.

Thanks!!

2 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: Domain Decomposition w/ multiple time steps

Hi,

oofem is open source,  so you will get it with complete source code, which allows you to interact and manipulate with all classes and associated data structures. OOFEM is object-oriented code, which also means that you don't manipulate the underlying data structures directly, but rather communicate with different objects to get some processing, to change their state, etc. You can have a look at oofem documentation and especially to oofem reference manual to see individual classes and their interfaces.
In general, you will have to extend some capabilities of oofem to deal with the problem you describe, but in general, I don't see any major issue. Try to go through oofem design (by browsing the code itself or perhaps reading some of the papers) to get feeling what it can do for you.

Borek

bp's Website

  • Registered: 26-07-2012
  • Posts: 7

Re: Domain Decomposition w/ multiple time steps

Thanks!

  • Registered: 28-07-2008
  • Posts: 71

Re: Domain Decomposition w/ multiple time steps

Hi,
To echo Borek's comments - OOFEM can be extended in many ways. The code base includes quite a few features that make it relatively straightforward to do a wide variety of things. In particular, the bookkeeping and a wide range of elements have already been implemented. There is a small but fairly active group of people doing development work on the code who do watch the forum.

That said, depending on your background in FEA and C++, it takes some time to figure out how all of the pieces go together and how the code works. I'd strongly recommend starting with implementing something small and easy before you set out to do the whole MGMT analysis.

-Erik

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Domain Decomposition w/ multiple time steps

MGMT sounds quite exciting, although it might get a bit tricky to implement this into any FEA code.

In the absolute worst case, if it turns out to be really really difficult to fit MGMT into OOFEM's design, then you could still just make your own problem class, element classes, your own materials, and just use the convenient input-file reading and solvers, etc,  from OOFEM.
I can't even imagine how MGMT would deal with nonlinear materials, or how it would export time history (OOFEM normally exports 1 file per time step), so its hard to tell how things will turn out.
It would of course be really valuable if this could be made to work without having to resort to new elements or material types. Do ask questions if you feel unsure on how to implement something. We can probably give you pointers on how to approach certain problems, and possible modify the core of OOEM to make your work easier.

  • Registered: 26-07-2012
  • Posts: 7

Re: Domain Decomposition w/ multiple time steps

hello,

I have been learning c++, object oriented programming and oofem itself for quite some time now.
I have a feeling that MGMT can be implemented into oofem without too many serious modifications.

I am looking forward to start my own mini-project on the side to do the same.

I have few questions about the capabilities of oofem and would appreciate if you could help.

(assuming 2 sub-domains in MGMT - A and B, let DT be the time step for A and dt for B, such that DT/dt = int)

1) I realize that the Domain class is used to represent a grid, so if I have 2 domains defined in my input file (for A and B), does the Engng model treat them as different entities and build (for example) the stiffness matrices for A and B separately- as two different matrices?

2) Can interface elements be used to connect two non-conforming sub-domains - A and B, say (for example) using mortar constraints? or is there another way to obtain constraint matrices (mass matrix) for the interface of non-conforming grids?

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Domain Decomposition w/ multiple time steps

1. Yes.
Multiple "Domain"s in OOFEM are currently only used adaptive analysis, where the second domain has higher order elements. So each domain is completely separate systems.
In parallel OOFEM we actually still use just 1 domain, but it's split into groups for each CPU.
There is no communication between the domains, unless your Engineering model specifically does that.

2. I'm not sure how this constraint matrix is defined, but (at least currently) elements can not communicate between difference domains. In fact, domains can't cleanly communicate with other domains.

You'll clearly need to add a new EngngModel for this, and I would suggest that you implement all the glue between domains in that class.
If you, as simple as possible, give a definition of how this matrix is defined I could give better advice on how to implement it.

  • Registered: 26-07-2012
  • Posts: 7

Re: Domain Decomposition w/ multiple time steps

Hey Mikael,

Thanks for your reply!

I have attached a link to the description of domain decomposition / mortar elements and the definition of constraint matrix (Q)

https://docs.google.com/file/d/0B-X2uD- … sp=sharing


You might also be interested in looking at: http://trilinos.sandia.gov/packages/moertel/
This is another open-source C++ package that handles contact algorithms using mortar elements. 
Source can be downloaded from the trilinos homepage.

  • Registered: 26-07-2012
  • Posts: 7

Re: Domain Decomposition w/ multiple time steps

a follow-up on 1).

so if the input file reads two domains, are these accessible in the engng model from the very beginning, or (as you mentioned) only during adaptive analysis time-steps?

10 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: Domain Decomposition w/ multiple time steps

HI,
I have an additional point to the second point: I can easily imagine the substructure element, that internally will group several elements (having Domain object as attribute) and will be able to return the characteristic matrices for interface nodes by condensing the internal DOFs, so it can act as usual element in oofem. Then you can develop mortar elements that will constrain these "substructure" elements within a single, top level domain, so there will be no need to have custom Engineering model.  This of course assumes that mortar elements can handle all the additional logic, but I assume they can. This has the advantage that existing Engineering models can be directly reused.

Borek

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Domain Decomposition w/ multiple time steps

1. Every engineering model has possible access to as many domains as you create. Most of the engineering models are hardcoded to use domain number 1, since they don't know what to do with the others.

Hmm
I would probably consider something like adding an ActiveBoundaryCondition on the shared boundaries.  You can find some examples of ActiveBoundaryConditions that introduce additional unknowns (e.g. unknowns traction on a boundary).
MixedGradientPressureNeumann does this for example.
Now, if you actually want to solve this in parallel as well, I'm not quite sure how I would design it.

While you could have this matrix with some interface type element without having to write your own engineering model, you definitely need to write a new one in order to use MGMT.