Dear Forum Wish you all a v
 

Dear Forum

Wish you all a very nice day.

I am working on on a model which requires more than one sliding interfaces. I looked into how mixerFvMesh works. Bases upon my understanding I present the extension. Please provide input as I still have some open questions.

When one uses icoDyMFOAM for the mixer2D test case this is how it all goes:

1) The
------
# include "createDynamicFvMesh.H"
-----
calls dynamicFvMesh::New() and creates an object of type dynamicFvMesh.

In the process of creation , the Member Function (MF) looks up dynamicFvMeshDict:
----
word dynamicFvMeshTypeName(dynamicMeshDict.lookup("dyna micFvMesh"));
-----
which return the value "mixerFvMesh". So an instance of class "mixerFvMesh" is created.

2)The mixerFvMesh constructor does the following:

-->initializes base class topoChangerFvMesh (this class contains a "polyTopoChanger topoChanger_ )

--> initializes motionDict_(mixerFvMeshCoeffs)
--> initializes csPtr_
--> initializes rpm_
--> movingPointsMaskPtr_(NULL)

after the initializer list it calls MF addZonesAndModifiers().

3) the MF addZonesAndModifiers() is where all the zones are defined at the initialization phase. Basically it does the following:

3.1) creating zones
--> create One point zone for cut points for the sliding interface
--> create three face zones
----> one for inner slider
----> one for outer slider
----> an empty face zone for cut faces
--> create One cell zone for moving cells

3.2) adding zones : addZones(pz, fz, cz)

3.3) add a topology modifier i.e .

--> Set topoChanger's size : topoChanger_.setSize(1);
--> Set the topoChanger's definition with

topoChanger_.set
(
0,
new slidingInterface
(
"mixerSlider",
0,
topoChanger_,
outerSliderName + "Zone",
innerSliderName + "Zone",
"cutPointZone",
"cutFaceZone",
outerSliderName,
innerSliderName,
slidingInterface::INTEGRAL
)
);
--> set ist write options
topoChanger_.writeOpt() = IOobject::AUTO_WRITE;
--> write it
topoChanger_.write();

--------------------------

The above operations are performed for one sliding interface corresponding to this dynamicMeshDict:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dynamicFvMeshLibs 1("libtopoChangerFvMesh.so");

dynamicFvMesh mixerFvMesh;

mixerFvMeshCoeffs
{
coordinateSystem
{
type cylindrical;
origin (0 0 0);
axis (0 0 1);
direction (1 0 0);
}

rpm 10;

slider
{
inside insideSlider;
outside outsideSlider;
}
}


// ************************************************** *********************** //

As per my understanding the extension of this setup for more than one interfaces should be trivial. For 2 interfaces the dynamicMeshDict shall be :
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dynamicFvMeshLibs 1("libtopoChangerFvMesh.so");

dynamicFvMesh mixerFvMesh;

mixerFvMeshCoeffs
{
coordinateSystem
{
type cylindrical;
origin (0 0 0);
axis (0 0 1);
direction (1 0 0);
}

rpm 10;

slider1
{
inside1 insideSlider1;
outside1 outsideSlider1;
}

slider2
{
inside2 insideSlider2;
outside2 outsideSlider2;
}
}


// ************************************************** *********************** //

The addZonesAndModifers() should define a set of
1 pointZone
3 faceZones
1 cellZones

for each interface and the size of topoChanger should be set to 2 : topoChanger_.setSize(2); and then it should be set for each sliding interface as :

topoChanger_.set
(
0,
new slidingInterface
(
"mixerSlider1",
0,
topoChanger_,
outerSliderName + "Zone",
innerSliderName + "Zone",
"cutPointZone",
"cutFaceZone",
outerSliderName,
innerSliderName,
slidingInterface::INTEGRAL
)
);


topoChanger_.set
(
1,
new slidingInterface
(
"mixerSlider2",
1,
topoChanger_,
outerSliderName + "Zone",
innerSliderName + "Zone",
"cutPointZone",
"cutFaceZone",
outerSliderName,
innerSliderName,
slidingInterface::INTEGRAL
)
);


I request the experts to comment whether that is valid. I know trying is the best way to find out its validity but I just wanted to get an opinion of experts before I jump into modifying code.

Any Input will be helpful

With Kind Regards
Jaswinder

Hello Forum A very good eve
 

Hello Forum

A very good evening to all

I have one further doubt related to the above post.
The creation of pointZones and faceZones can be repeated for each interface but i am not sure about how to extend the creation of cellZones for each interface.

As i understand, there has to be only one cellZone as it distinguishes between moving cells and non movingcells and this information can be combined into one cell zone for all the interfaces.

Any input will be helpful

With Best Regards
Jaswinder

Dear Forum I still hope som
 

Dear Forum

I still hope somebody with the info will answer

with best regards
Jaswi

Hello Forum Wish you all a
 

Hello Forum

Wish you all a nice day.

I have been able to extend the mixerFvMesh for more than one interfaces. The solution is simple. Just extend the faceZones and pointZones. For each interface one needs to add

3 faceZones
1 pointZone

Once the face zones and point zones have been defined one needs only 1 cellzone , which puts all the cells within these interfaces into one zone.

Anybody please correct me if I am on the wrong line of reasoning.

With Kind Regards
Jaswinder

Dear Jaswinder, I tried to
 

Dear Jaswinder,

I tried to follow your advice to include a second interface. The compilation worked well but when I tried to run the case I get an error

*** glibc detected *** icoDyMFoam: malloc(): memory corruption

Did you get it to work for your case? Could you maybe share the files or do you have any idea what I did wrong?

Thanks a lot,
Christina

Hi Christina I met with a s
 

Hi Christina

I met with a similar issue. It compiled for me but when I tried to run it on my case it used to crash.

In my opinion the reason lies with the workings of topological changes. With this I DO NOT mean that they are wrong, but one needs to understand its internal workings.

In my understanding for the case when you have two sliding interfaces one needs to detach them from each other before one tries to slide the faces of an individual sliding interface. If you take another look at the class interface of mixerFvMesh there is a switch:

//- Attach-detach action
70 Switch attachDetach_;

which i guess is used for this purpose. Also please not that this switch is listed as private data member of the class mixerFvMesh belonging to development version only, it is not present in the official version.

You best option is to ask Higher OpenFOAM beings as they can throw some light on it and bless the lower OpenFOAM beings , i.e., us with some comments :-).

Hope you will find the answer.

Kind Regards
Jaswi

P.S: You can also try the GGI version of the mixerFvMesh --> mixerGGIMesh. It is available with the 1.5 dev version. It may not have these issues as it does not move the mesh explicitly