[psosnows]

Since some time I have been trying to work with multi region cases, also with chtMultiRegionFoam. As it was written in this topic, one needs some effort to view results in paraview. The way of doint it was described by Andrea Barbera on 24.07.2008. It works fine, but generates files with the same names for each region. In the end one can open every mesh in paraview, but working with them is a bit tricky... I allowed myself ot write a little bash script to help in this matter ;)

It uses foamToVTK for conversion (or is supposed to do so) and changes the filenames in each region to its name. Hope some of you will find it usefull ;)

Pawel

[psosnows]

the file:

[mehulkumar]

hi..friends.
I am new to chtMultiRegionFoam.
I want to change geometry as per my problem.
I am not getting how to setup whole problem? I made outer domain using blockMeshDict file but not getting further...I think I have to make changes in makeCellSets.setSet file as per regionProperties. But setup of makeCellSets.setSet is not clear.
Please guide me if any one have idea!!!

Mehulkumar

[mehulkumar]

hi...I was able to make geometry using makeCellSets.setSet.
Now as per Allrun it wants to read changeDictionaryDict file.

Can anybody share information regarding this file.How to make it?How domains are define?

Pls raise your hands for beginner.
Thanks

Mehulkumar

[psosnows]

hello mehulkumar,

this is my interpretation of how the changeDictionaryDict works, check it, I belive it is ok

first of all you specify which fileds (files) to change:

dictionaryReplacement
{
T {...}
field2 {...}
}

In each of them you specify what to change
so, if you write inside T:
T
{
minY
{
type fixedValue;
value uniform 500;
}
new_boundary
{
type calculated;
}
}

It it will change minY and new_boundary to what you specify.
Note that if there are no fields named minY or new_boundary nothing will happen.

Is also appears that dict understands words like region0, solid2, fluid4 etc.
I belive the numbers refer to alphabetical order in constant/regionProperties or simply from folder listing (you will have to check it)

The other thing is that you need to have changeDictionaryDict in each of your system folder for each region you want to change.
In the end, I prefer to change those things manualy

and now I have one question:

I have notticed that fields K are a bit different in fluid and solid regions.
In solid ones, they are beeing read from files K and have dimension [ 1 1 -3 -1 0 0 0 ], when in fluid regions, they are beeing calculated:
[I]thermof[i].alphaEff() * thermof[i].rho() * thermof.Cp()
and their dimension is [2 -2 -3 -1 0 0 0]
It seems that multiplication by rho is wrong.

why is it like that? is it because solidWallHeatFluxTemperatureCoupled and solidWallTemperatureCoupled boundaries need it like that or is it some kind of mistake? Please give me some light on that matter.

[velan]

Hi All,

I tried the tutorial case of MultiRegionFoam. But i got the following error message.
vc@velan:~/OpenFOAM/vc-1.5-dev/tutorials/chtMultiRegionFoam/multiRegionHeater> chtMultiRegionFoam
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.5-dev |
| \\ / A nd | Web: http://www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Exec : chtMultiRegionFoam
Date : Apr 07 2009
Time : 16:31:07
Host : winslet
PID : 18172
Case : /home/vc/OpenFOAM/vc-1.5-dev/tutorials/chtMultiRegionFoam/multiRegionHeater
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create fluid mesh for region bottomAir for time = 0.001

Create fluid mesh for region topAir for time = 0.001

Create solid mesh for region heater for time = 0.001

Create solid mesh for region leftSolid for time = 0.001

Create solid mesh for region rightSolid for time = 0.001

*** Reading fluid mesh thermophysical properties for region bottomAir

Adding to pdf

Adding to thermof

Selecting thermodynamics package hThermo<pureMixture<constTransport<specieThermo<hC onstThermo<perfectGas>>>>>


Not Implemented
Trying to construct an genericFvPatchField on patch bottomAir_to_leftSolid of field h

From function genericFvPatchField<Type>::genericFvPatchField(con st fvPatch& p, const DimensionedField<Type, volMesh>& iF)
in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 45.

FOAM aborting

Aborted


I downloaded the case which send by Mattijs. Its working fine without any problem.

- Velan

[psosnows]

hi Velan,

it seems that your basicThermo model can not create h field.
if you look in the code, you will notice that h is created usually by class hThermo.
The constructor is here:
http://foam.sourceforge.net/doc/Doxy...ce.html#l00030

this field is generated from temperature filed T and other coeffs you specify in thermophysicalProperties.
in my opinion you have some trouble with T filed.

did you split mesh properly?
did you change dictionaries properly?
are the boundaries (and the field) of T correct? (maybe you have some misspeling?)
(at the beginning check bottomAir region in 0.001 time)
hope you will find this usefull

and I repeat my question from 2 posts below:

what is going on with K field in chtMultiregionFoam ?
why the dimensiones do not match for fluid and solid fields?

Pawel

[velan]

Hi Pawel,

Thanks for your reply. I found the where is the problem.

T file having the type

bottomAir_to_leftSolid
{
type solidWallMixedTemperatureCoupled;


SImulation running, If i changed the type to solidWallTemperatureCoupled,

Any ideas ?

- Velan

[psosnows]

hello Velan,

in chtMultiRegoinFoam you can select two specific wall types:
solidWallTemperatureCoupled (swtc).
solidWallHeatFluxTemperatureCoupled (swHFtc) and

The swtc replaced its own boundary values with those of the neighbour region. It also gives you a new function: flux() which returnes the heat flux in W/m^2 calculated using values at the cell next to boundary:
return Tw.snGrad()*patch().magSf()*Kw;
Tw is this patch, snGrad() returnes gradient of the value between the cell center of the cell next to the boundary and the point at the boundary (it has a dimension!).
patch().magSf() returnes dimensionless magnitude of face area
Kw returnes dimensioned K value of the filed (thermal conductivity)

The swHFtc sets the gradient function of the value at the wall. As far as I am concerned the solve() function calls the gradient function at some level to determine it for the matrixes. Usually it is determined somewhere else, but I swHFtc it is replaced by a new function.
it looks like this:
gradient() = refCast<const solidWallTemperatureCoupledFvPatchScalarField>
(neighbourField).flux()/K;
as you can see, here we call the flux() function that I described in swtc. We devide it by this fileds K (thermal conductivity) and get the gradient value between the regions scaled by their thermal conductivities.

The conclusion is: if you want swHFtc to work, you will need swtc on the neighbour patch. You can have two swtc on bot regions, but this way you will set both boundaries as the value of the second filed (in fact they will not be coupled).

This is just my interpretation of the code, I would be very grateful for verification by someone more expirienced but I hope it helps a bit.

and in the end... my question about the solver and tutorial case! (will not let it go )
can anyone help me understand why the dimensiones of K does not match for solid and fluid? is this a bug or should it be like this?

Pawel

[mik]

Hi all,

As I can see there are all expert in cht, so I could ask some help for my problem related to the Mesh region:

I have imported the mesh with

fluent3DMeshToFoam

as seems it work perfectly till I began with the code:

splitMeshRegions

the following error appear:

Mapping field S
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast
Aborted

I have already posted my problem (more precisely) there (the last one):

http://www.cfd-online.com/Forums/ope...shregions.html

but nobody responds.

Maybe here could I have more chance

Another important things I would like to ask is why does the command

fluentMeshToFoam

have this options: [-writeSets] [-writeZones] but the command

fluent3DMeshToFoam

doesn't have this?
(My .msh has already the regions specified, I need already to insert the commands [-writeSets] [-writeZones]?)

Please help me...

Thank you

Best Regards

Michea

[psosnows]

I recall we had a similar problem with exporting multi-region mesh from Fluent to OF.

Now, the thing depends on what do you want to achieve

In my case, I did not work on Sets and Fields. Each region had its own mesh. (maybe this is obvious, but I am a bit out of touch with newest approaches used in this solver).

In the end, if you simply want to get each region as a "separate" case connected by some coupling boundary condition, here is what we did:

We used Ansys CFX to create the whole mesh. Then in the generator, we decomposed it into regions, and exported each region independently as a .msh file (fluent format). I am sure simmilar thing can be done in Gambit.
Then, for each region we used fluent3DmeshToFoam in a tmp, non-multi-region OF study (i.e. icoFoam ), and moved acquired "polyMesh" folder to the final OF study.

In the end, we had to play a bit with "boundary" files (but you will have to do it anyhow).

If you have 100 regions, I recommend you to look for other method, but for up to 10 it works fine
About the difference between fluent3DMesh… and fluentMesh…- I am not sure, but believe that the 3D one is just the first one with some pre-defined options. Just to shorten work

[mik]

Hi all,
thank you Pawel for the advices, I have try but I have always some problem with boundary conditions...

For the problem I had before:

mapping field "S"

I have found a solution:
In the 0 folder (or the one, which represent the start time in our case) one has only to create a folder for each region and put the file inherent the variable inside this folders.

Another possibility is to create the region separately as proposed by Pawel.

My actual problem is the generation of the interfaces "coordinates" inside the boundary conditions in 0.001/<region>/polyMesh folder.

My case is a cell which represent a quarter (in order to reduce the computational time) of a bigger domain containing a cylinder in cross-flow with water. My cell is an half in length and an half in height, than i "compensate" with "symmetryPlane" boundary condition. I have only two regions: SOLID and FLUID.

With the command

splitMeshRegions -cellZones

one generates the folder 0.001 which contains a folder for each region. In the tutorial "multiRegionHeater" the boundary conditions located in: 0.001/<region>/polyMesh contains also some "coordinates" related to the "interface" between the region, which are in touch.
As example I put here the boundary from "heater"

...
    heater_to_topAir
    {
        type            directMappedWall;
        nFaces          40;
        startFace       172;
        sampleMode      nearestPatchFace;
        sampleRegion    region0;
        samplePatch     none;
        offset          (0 0 0);
    }
...

By typing "splitMeshRegions -cellZones" in my case (with separate mesh for each regions as well as from the complete mesh) I don't obtain this interface in my boundary condition inherent the mesh zone for each regions.

Can someone please help me?
How have you done (Pawel)?
(I have to much nodes and faces to make it "by hand")

Thank you

Best Regards

Michea

[psosnows]

The thing is actually quite simple

When you do create fields using split mesh, I am sure you get in the boundary files something like this:

patchName
  {
  type                      <typeName>;
  nFaces                  <some_number>;
  startFace             <some_number>;
  }

in fact, all you have to do is to complete the dictionary with data needed by the specific boundary condition used by mixedTemperatureCoupled (i.e. directMappedWall). That is, you have to add:

sampleMode                            nearestPatchFace;
  sampleRegion                          <name_of_neighbour_region>;
  samplePatch                             <name_of_patch_to_be_coupled_with>;
  offset                                          (0 0 0);

and also you have to change the type obtained form splitMesh into "directmappedWall" type. Of course you have to manually select names of the neighbour patches and regions. I recommend to check it always twice- some misspellings are common error (how do I hate it...).

sampleMode is the algorithm used to map one patch to another. In general, meshes do not have to mach 1:1, and probably there are some other algorithms of which I do not know. This boundary type is also used for parallel decomposition and was adopted for coupling. I am not sure what exactly "offset" does, but I believe it is not directly used and is there just to provide consistency with the earlier created general type. Leave it as it is

The only thing you have to specify in the file is sampleRegion and samplePatch.

Summing up, you take generated patches and modify them to get something like this:

patchName
  {
  type directMappedWall; // !! here you have to change the type generated by splitMesh to the "directMappedWall"
  nFaces                  <some_number>; // do NOT change this number, it is fine
  startFace             <some_number>; // same with this one, just leave it and do not worry
   
  // this is what you add:
  sampleMode                    nearestPatchFace;
  sampleRegion                  <name_of_neighbour_region>;
  samplePatch                     <name_of_patch_to_be_coupled_with>;
  offset                                   (0 0 0);
  
  }

Hope it helps you a bit

Best,
Pawel

[mik]

Hi,
I tried to do what you said but there is still something, which doesn't work.

First I have forgotten to ask you if you run

changeDictionary -region <region>

anyway or you just adjust all things manually?!

If I run "changeDictionary -region" in accord with the file changeDictionaryDict located in system/<region> adds at the end of the file boundary located in 0.001/<region</polyMesh the following code:

...
FLUID_to_SOLID
{
    offset          ( 0 0 0 );
    sampleMode      nearestPatchFace;
    sampleRegion    SOLID;
    samplePatch     SOLID_to_FLUID;
}
...

This is an example for the file boundary located in 0.001/FLUID/polyMesh in my case.
I need this or not? Because if one doesn't run "changeDictionary -region" one doesn't obtain this "additional" patch in the file boundary.

First I tried to add the type as well as nFaces and startFace taking the data from the only common patch among the tworegions (FLUID and SOLID) and this is the "mantle" of the cylinder (named CYL_INTER in my case).

So I become:

FLUID_to_SOLID
{
    type            directMappedWall; 
    nFaces          5733;
    startFace       828884;
    offset          ( 0 0 0 );
    sampleMode      nearestPatchFace;
    sampleRegion    SOLID;
    samplePatch     SOLID_to_FLUID;
}

and I have let the other patches (CYL_UP, CYL_DOWN, CYL_INTER, CYL_LEFT, CUBE_UP, CUBE_DOWN, CUBE_RIGHT, CUBE_LEFT. INLET, OUTLET) without changes, so only with type, nFace, startFace. CYL represent the SOLID region and the CUBE the FLUID one.

Typing directly "chtMultiRegionFoam" the error is:
see attached file error 1

The second method I have try is to change all the type of patches in directMappedWall and add the simpleRegion and Patch: (see example)

...
CUBE_RIGHT
{
    type            directMappedWall;
    nFaces          2891;
    startFace       852306;
    sampleMode      nearestPatchFace;
    sampleRegion    SOLID;
    samplePatch     SOLID_to_FLUID;
    offset          ( 0 0 0 );
}
...

But making so it sais that there is an "internal conflict" because for example CUBE_RIGHT patch is defined as type "symmetryPlane" in the initial conditions in 0.001 (U, T, p, k, ...).
See attached error2 file.

If I don't run "changeDictionary -region <region>" I don't obtain SOLID_to_FLUID (as example) in the boundary file but if I change the other as specified sais always that in intial conditions are defined as symmetryPlane and one can not change their type in directMappedWall.

So I hope is clear what I have explained, is not so easy be really clear!
If one needs also the mesh can I provide it...

Can you help me (again)?

Thank you

Best Regards

Michea

[psosnows]

The truth is that I did not use "splitMesh" directly, just looked at it in the chtMult... example. I did the thing "by hand". "changeDictionary" is just a smart way of automaticaly altering data fields and all other "needed" stuff in newly obtained folder with new mesh. I did not like the way data and meshes were stored after the „splitMesh”. For me, mesh should be stored in „constant” folder, not in any time directory, especially if you do not alter the grid during computations. The thing is, that if you use "splitMesh" you obtain additional "polyMesh" folders in new initial directory 0.001. And those are the meshes used by solver, and which should be modified and prepared for work etc. It always confused me and gave a lot of trouble for debugging and post processing, so I always created "tmp" case for decomposition, and "runCase" for the simulation, which had the mesh in "const" folder (copied from 0.001 tmp folder), and no meshes in 0 starting folder.

Now regarding the error files. It seems to me, that in the first case the mesh is OK, and the error is not caused by the coupling thing. (please next time send logs with line numbers, will be easier to describe what is what )

Just after "Adding thermoFluid" line you have several "warnings". They do not cause solver to crash, but tell about some inconsistance. In your case, in the data files of the initial time folder, you should add the keyword "uniform" after "value" entry and before the value. You probably have:

value <some_number>;

and it sbould be:

value uniform <some_value>;

This way you tell the solver that you want to have the same uniform value inside the whole region. Other choice is to put "nonuniform" keyword and after that the list of values (you can check how it looks for example in icoFoam test case in pressure file in any non-zero folder).
But as I mentioned, this is just a cosmetic thing.

The real problem is at the end of the log, in the section containing #1, #2...
Look at the fist line of this section:

incomputable dimensions for operation
[U[0 1 -2 0 0 0 0 ] ]+ [U[1 -2 -2 0 0 0 0] ] (...)

You specified wrong dimensions of your data. Look to the solver and check the velocity equation. The second term probably has some coefficient in it (viscosity?). And it seems that coefficient should be divided by density /OR/ its dimension in "const" folder should be divided by density dimension. You can also modify the solver


And now regarding the second case. The procedure of adding some lines and modifying the type of a patch should be only used for the patches that are to be coupled. So if you have some simmetry planes, just leave then as they are after „splitMesh”. In the end, I believe that when you fix the problems with the first error file, things should go smooth.

Best regards,
Pawel

[benk]

Hi, I have a question about this solver.

Usually the coupling is done between different regions. For example,

bottomAir_to_leftSolid couples between the fluidRegionNames and the solidRegionNames. This is only 2 regions.

How can I use this solver to couple between 3 regions? I need to model a geometry that looks like a sandwich with heat flowing through 3 different regions (ie. the middle region is coupled to both the left and the right regions, but the left region is only coupled to the middle region and the right region is only coupled to the middle region).

To do this, can I define a single region in the regionProperties file like:

regionName (
left
middle
right
);

and then couple like:

left_middle
middle_left and middle_right
right_middle

OR

would I need to define three new regions in the regionProperties file like:

leftRegionNames ( left );
middleRegionNames ( middle );
rightRegionNames ( right );

I think I'd need to define 3 new regions but my problem is when I do this, I also have to change the coupleManager.C file to account for this third region and I'm not sure how to do this.

[psosnows]

Hello Ben,

well, if you take a closer look at the regionProperties file in the exaple of chtMultiMultiRegionFoam, you will see that there are in fact only two dictionaries:

fluid(
   fluidName1
   fluidName2
...
);
solid(
   solidName1
   solidName2
...
);

regionProperties file determines which regions are supposed to be considered as solids and which as fluids. In the solver, you will find that there is a different approach to solve them (quite obvious).

Now, when we say "couple regions" in fact we mean to couple the temperature fileds. Observe that we never make connections fluid-fluid. This is because ONLY temperature is coupled, no mixing is allowed.

Now lets imagine 1D case, consisting of 3 solid regions: L, M and R. all of them are in general independent cases of temperature distribution with right and left boundaries.
In this case lets say that the regions have the following boundaries:

L: L_leftB, L_rightB;
M: M_leftB, M_rightB;
R: R_leftB, R_rightB;

we want "to couple" L<->M and M<->R. To do that, we set the boundaries as:

// pseudoCode//
L_leftB = fixedValue/fixedGradient/any_other_standard_BC;
L_rightB = solidWallTemperatureMixed connected to region M and M_leftB;

M_leftB = solidWallTemperatureMixed connected to region L and L_rightB;
M_rightB = solidWallTemperatureMixed connected to region R and R_leftB;

R_leftB =  solidWallTemperatureMixed connected to region M and M_rightB;
R_rightB = fixedValue/fixedGradient/any_other_standard_BC;

I suggest to make a picture, it will make everything clear

This way we have coupled M with both L and R.

If you still have some doubts, feel free to write.
Best,
Pawel

[mik]

Hi Pawel,

I don't understand some things...
You don't typ "splitMeshRegion" (because you add the regions separately) and this is OK, yet I make like you and seems it work fine.
Than you don't have the file "changeDictionaryDict" in the system folder because you don't run it. You said: you do it "by hand", so if I understand correctly one has to add in each variable file (U, T, rho, ...) the condition/s inherent the interface/s as example:

    ...
    bottomAir_to_heater
    {
        type            calculated;
        value           uniform 0;
    }
    ...

by hand. Correct?
Is right make like the tutorial: "type calculated" ?

Than as suggest by you I have put the meshes (SOLID and FLUID part) in constant folder and I have created a 0 folder, which contains a folder for each regions (one for SOLID and one for FLUID) and in this "regions-folders" there are the initial values for each variable (U, T, rho, ...). So the velocity dictionary U is located in 0/FLUID and not in 0/SOLID because SOLID doesn't need it (as well as p, k, epsilon). In the other hand also FLUID doesn't need (K, cp) and therefore this "variables-dictionary" doesn't exist in 0/FLUID.
Correct?

You add already there (0/<region>) the interfaces in the variable-file? (Like the code above as example: FLUID_to_SOLID ...)

Than in "constant" folder I have the file "regionProperties" and always a folder for each region (so FLUID and SOLID), SOLID folder contains only polyMesh and the modified boundary conditions: (in the common face I have change the type in directMappedWall and add sample...:

    ...
    CYL_INTER
    {
        type            directMappedWall;
        nFaces          5733;
        startFace       739451;
        offset          ( 0 0 0 );
        sampleMode      nearestPatchFace;
        sampleRegion    FLUID;
        samplePatch     FLUID_to_SOLID;
    }
    ...

In the FLUID folder I have as well the polyMesh folder (with modified boundary) as the file inherent the fluid properties: (g, RASProp., thermoph... and turbul...).

Do you think it is correct?

in the same way in "system" folder I have files (controlDict, decomposeParDict, fvSchemes, fvSolution) and the two folders FLUID and SOLID, which contains the same files as the folder "system" (so: controlDict, decomposeParDict, fvSchemes, fvSolution ).

So if I have understood correct I don't need to add the following code:

FLUID_to_SOLID
{
    offset          ( 0 0 0 );
    sampleMode      nearestPatchFace;
    sampleRegion    SOLID;
    samplePatch     SOLID_to_FLUID;
}

in the boundary conditions of FLUID or SOLID (with sampleRegion ans Patch inverted) located in constant/FLUID/polyMesh or constant/SOLID/polyMesh.

Than under samplePatch is correct to insert SOLID_to_FLUID, which are two regions and not two patches...

I have try to run the above explained case typing "chtMultiRegionFoam" (I will make the decomposition when the case works) and the output is attched as log file
I have name the case "pawel" because is made as you have adviced (without mesh in the time folder)

can you please help me again?

Many thanks

Best Regards

Michea

(Scusa se ti carico di domande ma devo riuscire a far funzionare questa simulazione il pirma possibile! GRAZIE)

[benk]

Hi Pawel, thanks for your reply. If I understand you correctly, this solver only allows you to couple fields between regions and not within regions therefore, my regionProperties file would need to look like:

leftRegionNames ( left );
middleRegionNames ( middle );
rightRegionNames ( right );

I just had a look at chtMultiRegionFoam in OF1.6 and it seems to have changed slightly since 1.5. In 1.6 there is no longer a coupleManager.C file that has to be dealt with. I'll have to investigate chtMultiRegionFoam in 1.6 more closely.

Are you using 3-regions in this solver?

[psosnows]

Hello you both


in the order of questions, regarding Michea's post:


The questions- yes, you are correct.
But I will try to write step-by-step tour to make everything clear.

1. create TMP case using icoFoam, delete all fields in 0 folder.
2. Create runCase using chtMultiRegionFoam example
   1. in the run case, create folders for all fluid and solid regions,
      1. in 0 folder you need specific data fields (just as you described)
      2. in constant you need region folders with files as you described (you do not have polyMesh folders yet)
      3. in system folder you need:
         1. fvSchemes and fvSolution files in each regions' folder
         2. controlDict file just in main system folder (only this one is used)
   2. now you ''fill'' the runCase with polyMesh'es, for each region:
      1. copy .msh file to TMP
      2. run fluent3DMeshToFoam (or other converter)
      3. move acquired polyMesh to the corresponding folder in runCase
   3. Now the hard part check each boundary file in each polyMesh to alter the ''coupling'' patches (by changing the type and adding lines we discussed)
   4. for each region in 0 folder and for each file there, you have to specify the right boundary list. Usually it requires changing the names, adding or removing additional ones... and of course we have to take special care for ''coupling'' patches (additional lines in the dictionaries)
3. right now we should be ready to go.

Now, the error that you have comes from some wrong data assignment... It seems to me there is something wrong with the pressure or the density of the fluid. I think the program breaks on the line 133 of the createFluidFields.H file. At the same time, there can be something with creating solid fields. I suggest to add line

Info << “fluid is done” << endl;

between the line 151 and 152 of createFluidFields.H. (Make backup of the solver before modifying it). Then compile the solver and run again. If you get the message, there is something wrong in the regionProperties file with the solids, if not, look at the density and the pressure file of the fluid.


Last remark, the procedure I described is indeed a bit tricky, and requires a bit work. Using splitMesh and changeDict can save you some time. Unfortunately I did not force myself to study it in a way so I could use it, and at present time I am not working with OF much (hope to get back to it soon). That is why I do not feel qualified to help you with splitMesh procedure.




Wow, that will be a big post

Now to your question Ben,

I run a modified version of cthMultiRegionFoam for nine regions, 4 fluid and 5 solid

I did not fully understand your statement:

Originally Posted by benk

this solver only allows you to couple fields between regions and not within regions therefore

What do you define as “region”? For me, it is an element of the case which has different physical parameters from the others (other temperature diffusion coefficient etc). If you want to split one solid 'region' into two domains, then simply make two meshes which have a common patch, set all properties the same for both and couple their temperature with solidWallMixedTemperatureCoupled condition. This BC works only for solid-solid or solid-fluid interfaces. Fluid-fluid ones need some special care with pressure, velocity, mass conservation...

I will try to clear the things out on an example.
Suppose we want to simulate heat transfer in a computer. We will take a look at following components:
air in the computer, metal radiator (fully covering the processor) and plastic motherboard. The processor is a ''viod'' space and is represented as a fixed temperature BC. In the regionProperties file for this case we will have something like that:

fluidRegionNames 
 ( 
     AIR
 ); 
  
 solidRegionNames 
 ( 
      MOTHERBOARD
     RADIATOR
 );

If you for example want to add the housing of the machine and surrounding air, you will get in the regionProperties file something like that:

fluidRegionNames 
 ( 
     AIR_INSIDE
     AIR_OUTSIDE
 ); 
  
 solidRegionNames 
 ( 
     HOUSING
      MOTHERBOARD
     RADIATOR
 );

And by setting proper coupling boundary conditions you can make the case work. The following list presents the boundaries in pseudo-code:

RADIATOR:  
     coupling_air_inside,  
     coupling_motherboard,  
     fixed_temp_processor;
MOTHERBOARD:  
     coupling_radiator,  
     coupling_housing,  
     coupling_air_inside;
HOUSING:  
     coupling_motherboard,  
     coupling_air_inside,  
     coupling_air_outside;
AIR_INSIDE:  
     coupling_radiator,  
     coupling_motherboard,  
     coupling_housing;
AIR_OUTSIDE:  
     coupling_housing,  
     out_world_bc;

Each patch with coupling name needs to be set as solidWallMixedTemperatureCoupled and connected as in the tutorial example with corresponding neighbour region. Of course in our case the AIR_INSIDE and AIR_OUTSIDE are not 'touching' each other.


If you still are not convinced, I can provide you with an example case which couples 3 solid regions. (tomorrow, I do not have it at home ).


Woah, that was a bit writing... Hope that I helped a bit you both.
Best,
Pawel