Dear Carl,

it is true, that MacroLSpace elements has the RVE on itself, not in every integration point. What you want, is to have RVE in every integration point.
The solution would be to create a new material class (macro-material), containing related micro-problem representation. Any action on any macro-integration point will then be translated by the macro-material to its micro-problem, prescribing appropriate boundary conditions, evaluation of the response, followed by some homogenization. I see no problem for micro-problem to solve Stokes Flow while macro problem solving Darcy flow.
Some inspiration could be taken from macroLSpace element. However, there are some things, that could be done differently: each macroLSpace contains its own instance of micro-problem. This could be done much more better, as the RVE will be typically the same. In your case, the RVE could be shared for all gauss points of the same material (so it will be a property of macro-material, this does not mean that you could not have different RVEs, in this case, one will simply create more instances of macro-material, each with different underlying micro-problem). This more efficient design requires to store the history (and state) for the microproblem for each macro integration point. This is not difficult to implement, as each material comes with its material status, and its  unique instance is created for every integration point. In this case, the macro-material will define its status, that will contain an object storing the micro-problem history for corresponding macro integration point.  The history could be stored and restored using already available services (store&restore context) into the DataStream. DataStream could be a file, but also a memory buffer as well (this needs to be implemented, but not a big deal).
I would recommend to follow this, rather then the raw-force approach used in macroLSpace Element, as the duplication of micro-problem leads to very high memory demands,

The parallel computation should work, if the macro-material will be implemented correctly. But note, there is no parallel support for flow problems now, but it could be easily added - its basically just creating a suitable linear solver and making some changes in nonlinear solver (some communication to evaluate global norms correctly, etc), but most of the serial code is retained without change.

I could help with design of macro-material, as this will allow to recast the macoLSpace as well. One could create some parent class, problem independent, that will provide common support for such a kind of materials.

Borek

Dear Carl,

I can imagine, that the boundary conditions of the micro-problem should be communicated with corresponding macro-element. The macro-material should be responsible for doing this by directly manipulating the micro problem (adding new boundary conditions, associating them to corresponding nodes, elements, etc.), before solving the micro response. This will require, that macro-elements will provide some methods to query applied BCs. You may also include all possible BCs in micro-problem and only switch them on/off based on actual applied BCs on macro level, but I consider this to be less general.

Concerning the parallelization, I don't have any documentation ready. Perhaps the simplest example is linear static implementation (linearstaic.C in sm module), The parallel sections are marked with  __PARALLEL_MODE directives. You may have a look on it. If you just want to get your linear system solved in parallel, the work required is even simpler, as only modification in solveYourselfAt() method are required. The additional stuff is needed to correctly compute reaction forces of supported nodes on  inter-partition boundaries. I will try to prepare some introductory material at oofem wiki, but need to save some time.

Borek

Hi Borek!

I have been putting some thought into the RVE material. I have the following suggestion:

* First, a material, rvematerial, is created. It is a direct decendant to the Material class. rvematerial is the baseclass for all rve materials. rvematerial takes care of loading and instanciating the EngngModel object (rve) for some specified file. The decendants to rvematerial implements the giveCharacteristicmatrix function that sets boundary conditions on the EngngModel and then solves the rve and returns the characteristic matrix. The material in the .in file would look something like

rveStokesFlow 1 file "./rve_StokesFlow.in"

where rve_StokesFlow contains the complete problem except boundary conditions.

* Boundary condition are imposed by material driver on the engineering model and created during run-time. This is done by decendants to rvematerial to maintain scalability. For the material driver to be able to distinguish which nodes are located on some boundary, it is necessary to specify this in the .in file. Or maybe there is any other way to determine which edge of the domain an edge of an element or a node is located?

* Once the rve problem is solved, the result has to be averaged. In order to get this to work, the element class used has to be able to integrate the result (stress, strain, velocity, pressure etc.) over its area/volume. The rvematerial class then loops over each element in the rve and calculates the averaged value. The reason that the elements should be responsible for the integration of the result is that it would take too much work to implement all possible combinations of elements and shapefunctions into the rvematerial class. An idea is to create a class called 'rveElementCapabilities' that gives elements the capability to be used in homogenization. The elements can then inherit (in addition to whatever other class is inherited) decendants to rveElementCapabilities that contains the necessary functions, for example a function

            giveIntegratedQuantity(DofID id, double *Area, double MeanValue)

for the integrated quantity.

Since the engineering model is loaded at the material level, it is only loaded once as there is only one instance of each material.

So what do you think of this suggestion?

/Carl