[benk]

Hi Pawel, I appreciate your help. So from your example, it seems as if I was wrong because you can couple between elements within a region (ie. heat can be trasferred through the HOUSING then through the MOTHERBOARD then through the RADIATOR acting like three resistors in series.

What I mean by region is fluid (as in fluidRegionNames) and solid (as in solidRegionNames). My application is in electrochemistry so I need to figure out if I need 1 solid region containing cathode, electrolyte and anode or if I need 3 regions which would be cathode region, an electrolyte region and an anode region.

[psosnows]

Hi Ben,

now everything is clear!
Sorry if I confused you at the beginning, it seems we misunderstood ourselves.

Now regarding the approaches of which you talk about.

As far as I know, both ways are possible in OF.

The 'one-solid-region' and 'one-fluid-region' case requires a solver which deals with Sets and Zones to specify the elements. That is not chtMultiRegionFoam case. (In fact I do not recall a solver which does it like this, but I have not looked for it )

The second approach consider each element as a separate region. And that is done in chtMultiRegionFoam. The 'pipe-like' heat transfer is 100% OK in this case (in both approaches is). If you take a look in the tutorial of chtMultiRegionFoam, you will see that we deal exactly with this case.

In your case, as you said, you will need 3 solid regions. So the regionProperties file will look something like this:

fluidRegionNames
(
// there is nothing here ;)
);
solidRegionNames
(
ANODE
ELECTROLYTE
CATHODE
);

Consider that the solver always solves the fluid regions first, and then solid ones, in the order in which they are written in regionProps.

Best regards,
Pawel

[mik]

Dear Pawel,

I have tried to run the simulation the whole day but, as you can imagine, without success!

I ask you again some basilar things I have made to have a confirm.

I have followed you steps...
All clear and without any questions just the point 3 related to the boundary file located in constan/<region>/polyMesh.

My mesh consists in two part: a SOLID and a FLUID one, the SOLID is an half of a cylinder and the FLUID is the surrounding fluid. In total are 10 patches and only one is the common patch named CYL_INTER. It represent the only part "in touch" among the two regions, and is the "mantel" of the cylinder (external surface).

When I import the whole mesh using "fluent3DMeshToFoam" it recognizes two regions and name it SOLID and FLUID, therefore I use the same name. I have insert the name SOLID and FLUID in the regionProperties file located in constant folder.

I separate the two parts and import these singly.
I copy the polyMesh folder of each region in constant/region of the chtMultiRegionFoam case folder.
In the boundary file of the FLUID region I have 7 patches and in the SOLID one 4 patches.

In the boundary files I have change the type and the sample... for the common patch (CYL_INTER), so at the beginning was:

    CYL_INTER
    {
        type            wall;
        nFaces          5733;
        startFace       828884;
    }

and after the modification is:

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

for teh FLUID and:

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

for the SOLID.

It is right insert FLUID_to_SOLID an respectively SOLID_to_FLUID in the samplePatch ?
I have a doubt because FLUID and SOLID are region and not patches...

Then in boundary I have already modify the type of each patch beacuse during the importation it save all as type "wall" and I have also "symmetryPlane" type, but of this modification i am sure it is correct.

The other modification I have done is in the variable file (U, rho, p, T, ...) located in 0/<region>. I have adapt all the "symmetryPlane" patches and I have added in the end of the file the following code:

    FLUID_to_SOLID
    {
        type            fixedValue;
        value           uniform ( 0 0 0 );
    }

This one is taken from the U file of the FLUID region.

To help you to better understand my geometry and the modification I have done I attach a image of the whole mesh as well as the files located in 0/FLUID.

I have noticed that I have also a faceZones file in polyMesh which in paraview is defined as int_FLUID and int_SOLID and represent the internal "faces" of the mesh, what I have to do with this? I don't have to define it as a region int_FLUID ?

If you can help me, it would be marvelous!

Thank you very much

Best Regards

Michea

(the error I get is always the same, I have added the code you said in the createFluidField.H and it doesn't appear, but I don't find any error in the rho an p file!)

[mik]

Dear Pawel,

this message is only to provide you more images of my case.

Many thanks

Michea

[psosnows]

I believe you messed up with names of the "coupled" patch on both sides.

First of all: The name of the patch is created in the boundary file. If you use any patch name that is not specified and defined there, it simply does not exist

you use:

samplePatch FLUID_TO_SOLID;

where FLUID_TO_SOLID is the name of the patch of the neighbour region. Look at your boundary files. There are are no patches named like this, they do not exist

Lets do this thing from the top:

- you already have 2 regions: SOLID and FLUID. The names are uppercase, folders in 0, constant, system are uppercase, and from now on, any time you refer to a region name, you use uppercase SOLID or FLUID (for example in regionProperties you have uppercase SOLID and FLUID).

- go to boundary files of both regions. Change the names of the "coupled" patches form CYL_INTER to SOLID_TO_FLUID in the SOLID boundary file and to FLUID_TO_SOLID in the FLUID boundary file.

- go to each data file for both regions in 0 folder. You can erase entries CYL_INTER {...}.

- at the same time, in each of the data files you need to specify the SOLID_TO_FLUID (for SOLID region) and FLUID_TO_SOLID (for FLUID region).
- - for T files you need something like:

FLUID_TO_SOLID // or SOLID_TO_FLUID depending on reigon
    {
        type            solidWallMixedTemperatureCoupled;
        value           uniform 300;
        neighbourFieldName T;
        K               K;
    }

- - for other scalar fields (rho, p etc) for the coupling patch use simply zeroGradient (or this strange buoyantPressure for p if you like, and know what it does).

- for rho file use zeroGradient boundary type at the coupling. If you like, you can use calculated one, but do not be surprised to get some strange error which you do not where comes from :P

Pay attention that we used everywhere uppercase names! Misspellings are a common and hard to find error

After all that modifications, the case should start running

[mik]

Dear Pawel I have found an error, if one corrects it the simulations starts...

Yet I have to understand if it works fine. (but I am not so sure)

The error was the value of the output in the pressure file of the FLUID, instead of 0 I have insert 1e5.

What do you suggest for the number to insert in the other file I have send to you?

Many thanks

Best Regards

Michea

[mik]

Dear Pawel, many thanks for the last post it was really clear and thanks to this I have understand more important things...

I say only (if someone has to do a similar work) one has to insert FLUID_to_SOLID, so to has to be in lower case letter, if one inserts the capital case (TO) doesn't work.

Yet the simulation start and run but I still have some problems...

Also the decomposition for parallel computing work fine.

The question is how to "control" the simulation?
Because in the controlDict file located in system folder one can give some entries to control the simulation, as for example the time step but my simulation make a kind of "self-management" and doesn't care about the values... hehe

Instead of

writeControl     adjustableRunTime;

which gives the following error:
see attached file log
I have insert

writeControl    timeStep;

as is for solver like icoFoam and simpleFoam.

Only to probe I have insert deltaT = 1 with startTime=0 and endTime for the moment I have set 10 [s].

Only to show you what kind of deltaT "chooses" my simulation (somethings like 5e-09 [s]) I attach you a file with the first steps of the simulation named "simulation".

What do you use to ensure a "controlled" simulation?

Another important question I have to ask you is
if you have work with a fluid or a gas.

Because I have to work with a fluid and therefore I have to change the propreties in the file thermophysicalProperties located in constant/FLUID but is not so easy.

I have found a lot of posts releted to this topic but nothing conclusive, maybe can you help me also there!
This is defined for air:
thermoType

hPsiThermo<pureMixture<constTransport<specieThermo<hConstThermo<perfectGas>>>>>;

mixture         air 1 28.9 1000 0 1.8e-05 0.7;

I have to convert it in for water.
In the meantime I continue to search an answer.

Also this time thank yuo very much

Best regards

Michea

[psosnows]

Hi Michea,

Regarding time step control: in the controlDict you have a lines:

maxCo           0.3;
adjustTimeStep  yes;

adjustTimeStep tells, that the time step can change during simulation.
maxCo is the maximum allowed Courant Number.

If you allow to change time step duting the simulation, then if the local Courant number in any cell in your domain becomes greater than maxCo, the time step is reduced to match the maxCo.

It seems that for your mesh size, velocity of the fluid and viscosity, the maximum time step is the one that the solver chooses automatically.

Remember that if Courant Number grows over one, you loose stability.

To increase time step, you can: change the mesh, change the viscosity or reduce the speed. There is lots of theory about this in the books.

If you want to force the simulation to run with your time step, change adjustableTimeStep to no; but dont blame me if your results are untrustworthy or the simulation crashes

Regarding the thermophysicalProperties, take a look at OpenFOAM User's Guide Chapter 7

Best regards,
Pawel

ps
The thing with upper case "TO" is a total mystery for me... In fact I always use mostly lower case names, so I never encountered the problem. Strange...

[mik]

Hi Pawel,

ok , thanks for the explanation inherent the time step.
I set the right fluid properties with the right inlet velocity than I correct the timeStep (I hope i don't have to adjust it!).

My actual problem is to set correctly the FLUID properties contained in the file thermophysicalProperties located in constant/FLUID.

In accord to the chapter 7 of the UserGuide I have tried to create (adapt) the thermophysicalProperties file but I make something wrong because doesn't work.

Because i have water hRhoThermo as thermal model than pureMixture (because is only water) hConstTransport (c_p is almost constant in my case) and polynomimalTransport because I have a polynom for mu as well as for kappa which depends from the temperature.
For example for mu i have the following polynom:

Dynamic Viscosity = -4.022435897255712e-13 [Pa s K^-5]*T^5 + 6.825882502646741e-10 [Pa s K^-4]*T^4 - 4.636072465206497e-07 [Pa s K^-3]*T^3 + 1.576161911104011e-04 [Pa s K^-2]*T^2 - 0.026843268062385 [Pa s K^-1]*T + 1.834257498349647 [Pa s]

So inspired from the example for the janafThermo, which uses polynoms, I have tried to insert the polynom:
In order I have insert the one referred to mu and than the one for kappa.
I have insert the coefficents of the polynom in this order:

a_0 a_1 a_2 ... a_n

where the coeff. a_n is multiplied for the n-th power of the temperature (T^n).
Unfortunately doesn't work!
I have to specify also the variable T in the polynom instead of write only the coff.?
I attach you the file I have modify as well as the error.

The error is apparently not related to the polynomialTransport (see error1) but if I change it in constTransport and then I give two values (one for mu and the other for Prandtl-number) it gives a different error (see error2).
It seems it doesn't accept hRhoThermom as entry, but is the only incompressible!

The only thermophysicalProperties file I have found with deal with water is also attached (thermophysicalProperties1) but seems not so clear...

Another question I wont to ask you is if it is possible to insert the Thermal Conductivity (K) as well as the Specific Heat Capacity (c_p) as a polynom which depends on the temperature?!

I have made a modification in the file T located in the solid region:
I have insert an heat flux at the bottom of the cylinder:

    CYL_DOWN
    {
        type            solidWallHeatFluxTemperature;
        K               K;
        q               uniform 25e04; // [W m⁻2]
    value           uniform 300; // initial Temp [K]
    }

instead of

    CYL_DOWN
    {
        type            zeroGradient;
    }

and yet I am confuse regard the conditions I have to insert in the coupling SOLID_to_FLUID.
Because there isn't a boundary condition as "conservetive heat flux" I have to let as before?:

    SOLID_to_FLUID // conservetive heat flux ?
    {
        type                solidWallMixedTemperatureCoupled; 
        value               uniform 300;
        neighbourFieldName     T;
        K                   K;
    }

Why is defined as "solidWallMixedTemperatureCoupled" and not only "solidWallTemperatureCoupled" ?
An than I don't have to insert also the neighbourRegionName and the neighbourPatchName as specify in the tutorial ?:
http://www.tfd.chalmers.se/~hani/kurser/OS_CFD_2008/chtFoam.pdf

The last question is if I have to insert the value if the specified type is zeroGradient?
Also If I have correct understood only if the value is different from the one specify in the internalField, true?
Because zeroGradient boundary sais that at this patch there are the same condition as in the internalField?
I attach you some example (p_FLUID, rho_SOLID, K_SLOID in the next post )...

Many Thanks

Best Regards

Michea

[mik]

Hi Pawel

some files...

Michea

[psosnows]

Hello Michea,

regarding usage of thermophysicalProperties.
Maybe I will sound a bit not-Foam-like, and step out of the main trend, but I did not use this mechanism in my simulations. I modified the solver in the way to drop this method. Because of that, I will not be a great help in this matter. You have to dig through the code yourself, or find someone more experienced in that matter, sorry...

But, if you take a look to your thermopshysicalProperties file, look at the line defining Dynamic Viscosity of water. It seems there should be 6 constants (a_0 - a_5), while you provide 7. Maybe this is the problem?


The same with dealing with polynomial definitions of variables. I am sure it is possible to write your own code to deal with polynomial constants. It will be a bit work: make solver read coefficients, store them, use them, save acquired value as a field or constant...

On the other hand, is it really necessary to provide that much of complexity to the studied system? (this is just a philosophical question )

zeroGradient means exactly this: you have exactly the same temperature at the boundary, as the temperature on the next-to-the-boundary cell. You do not need to provide value, it will be ignored during calculations.

Regarding solidWall(...). In previous version of OF there was the solidWalltemperatureCoupled condition. While using this, you had to define neighbourField/PatchName inside the T file. At the same time, in the boundary file you had just the type patch.
In OF version 1.6 the solidWallMixedtemperatureCoupled condition was introduced. In it, the neighbour patch and field are determined inside the boundary file (by directMappedPatch type). While in T file you specify the things like in the tutorial.

The Mixed in the name regards the way this boundary works. Depending on the direction of the heat flow in each of patch’s face, it changes to Neuman or Dirichlet condition. So for example, half of the boundary is Dirichelt, half is Neuman. Is this physically correct? For me it is an open question, but this coupling works (even one can say it works quite good).

[Canesin]

Hi all,

I'm just sniffing in (sorry for that), but if I lear how this works I will try to help =) ..

So, there are 3 kind of BCs for coupling:

solidWallTemperatureCoupled: fixed value for temperature
solidWallHeatFluxThemperature: heat flux BC for temperature on solid ??
solidWallHeatFluxTemperatureCoupled: Fixed heat-flux at BC ..

So in my case I have an flux that change direction with time, I want to trace de profile of solid temperatures with time.. so I use the second one ?? this heat-flux BC is not fixed ?? It will change with time, is just a condition to "start" ?? Can anyone help ?

[mik]

Hi Pawel,

thanks for the inputs...
Maybe I will try to create somethings to use variable rho and K!
(but also the philosophical question is interesting and attractive hehe )

What is your Idea inherent the heat flux at the cylinder Bottom? (see attached file)
o you think it is ok?
It is not in contrast with the one in the SOLID_to_CYLINDER (copling Patch) ?

The last question is how can you visualize the results because I tried to use

paraFoam

as well as

paraFoam -touch <region>

but without any positive result!

One has to convert in VTK ?
The tutorial convert the regions in VTK at the began of the simulation, but I can0t because I don't run the following commands:

setSet -batch makeCellSets.setSet
setsToZones -noFlipMap

(the first generate the VTK files).

Thank you again...

Regards

Michea

[psosnows]

Ciao Fabio,

solidWallTemperatureCoupled and solidWallHeatFluxTemperatureCoupled are the old ways to couple temperature between regions. Do not use them. It is better to switch to solidWallMixedTemperatureCoupled. It is available in OF-1.6.

solidWallHeatFluxThemperature works the way you assumed. It allows to introduce constant heat flux to a patch (it has nothing to do with coupling).

Now, regarding the varying in time BC, there is a boundary called: timeVaryingUniformFixedValue. You define this boundary type in data file like this:

patchName
    {
      type             timeVaryingUniformFixedValue;
      fileName         "varyingDataFile";
      outOfBounds      repeat; // "clamp" force to clamp on the last value for further time steps
    }

in addition you have to provide in the main case folder the file varyingDataFile (you can name it another way...). The file has to have the following structure:

(
   ( 0    2313 )
   ( 1    3241 )

   ( ... )
)

the first value is the time step, the second is the value at this time step. All values in between will be linearly interpolated.

If you want to have a time varying heat flux, you will have to find something similar, or write your own code (using example) or switch to fixed temperature.
Hope this helps you a bit, good luck


Now moving to Michea's questions.
Regarding the question about the bottom cylinder patch: in my opinion everything is OK.

About the post processing:
first you run command:

paraFoam -touch -region REGION_NAME

for each REGION_NAME you have.
Then you run:

paraview

It opens paraview post processor. You use "OPEN" option to open all previously created .FOAM files. And thats it

With best regards,
Pawel

[mik]

Hi Pawel,
I still nedd you... hehe

I have tried for the whole day to implement liquid water in my model (instead of air) but nothing to do!

I have also ask at some people working with OpenFOAM here at the ETH but nobody has an idea.

My problem is that

icoPolynomial

equationOfState for liquid is not "activeted" in this version, the only possibility one has is to use

perfectGas

.
I think this beacuse if one take a look at the file "hRhoThermos.C" located in:
/home/<username>/OpenFOAM/OpenFOAM-1.6/src/thermophysicalModels/basic/rhoThermo/hRhoThermo
doesn't contain also a "combination", which take into account the option icoPolynomial as for example this one:

makeBasicRhoThermo
(
    hRhoThermo,
    pureMixture,
    sutherlandTransport,
    janafThermo,
    icoPolynomial //instead of perfectGas
);

I have tried to add the above code (makeBasicRhoThermo(...)) than add

#include "icoPolynomial.H"

At the begin of the "hRhoThermos.C" file and recompile this useing Make folder located in
/home/<username>/OpenFOAM/OpenFOAM-1.6/src/thermophysicalModels/basic
usign

wclean
wmake libso

but nothing to do...

I have write the whole stuff only if someone wont to make the same things maybe if he doesn't fail (as me) can help me...

I have write this only to ask how have you done?!

Have you write constant entry (cp, kappa, mu, ..) in the thermophysicalfile and than have you said at the solver to import this?

Can you please tell me your steps to have a working simulation with the desired medium ?

Again many thanks

Regards

Michea Ferrari

[psosnows]

Hi Michea,

about the hRhoThermos.C I would strongly recommend not to modify the original files in OF-1.6 folder.
Remember about "redefinition" feature of C++.
Copy the folder hRhoThermo to your case, add some lines to files and options files in Make directory to force compilation. Then include the files to your solver. This way you will work on "locally" changed hRhoThermo files, and will not "destroy" everything else, and will not be forced to recompile whole OF libraries. (And once again, sorry but I do not know much about usage of these libraries)

Now regarding the approach that I used.
- first of all, I deleted the thermo model from the solver;
- supposing one wants to work with constant coefficients, we create those that were "removed" with thermo model inside the createFields.H files (like thermal diffusivity, density etc). We can use dimensionedScalar type (good example of reading constant coefficnet is in icoFoam solver- look how nu is being read).
- of course you have to go through all the code of the solver and change any reference to thermo model to the newly created constants.

In the end you acquire a solver "clear" of automatic model, which reads constants defined by you.

Now regarding coefficients that wary with the change of certain parameter (for example in polynomial way):
- in the similar way as above, we can read and store the coefficients of polynomials.
- one can write a function, which taking as input the polynomial's coefficients, and basic value (average temperature, etc), and throws out a new value of a coefficient.

These are just general hints, but I am sure it is not hard to implement it. And in addition, you gain a lot of understanding about what is going on "inside" OF. Sometimes it is simply easier to write your own, not "purely" OF-like code than to fight with something witch is not fully documented. Or you can buy some parts of the code that works

Best,
Pawel

[mik]

Dear Pawel,

thanks for the inputs, also the one related to the OF library...

I have some "organization" questions...
If I write all the variable (thermal diffusivity, viscosity, ...) in a file named e.g. properties than can I recall always the same file (structure) and only change the .<variable>, so as example:

    IOdictionary properties
    (
        IOobject
        (
            "properties",
            runTime.constant(),
            mesh,
            IOobject::MUST_READ,
            IOobject::NO_WRITE
        )
    );

    dimensionedScalar nu
    (
        properties.lookup("nu")
    );
    dimensionedScalar nu
    (
        properties.lookup("K")
    );
    dimensionedScalar nu
    (
        properties.lookup("<otherVariable>")
    );
eccetra

So use only one "head":

    (
        IOobject
        (
            "properties",
            runTime.constant(),
            mesh,
            IOobject::MUST_READ,
            IOobject::NO_WRITE
        )
    );

Which contains all the constant to insert in the code?
It is for you feasible ?

For the coefficients polynomial function I don't have understood how to use it...
If I, in my file properties, define the one variable as a function of T:
a_0 + a_1*T+a_2*T² ...
it works ?
The solver take the old value (so previous iteration) of the temperature and insert it in the polynom?
Otherwise I don't understand how can I extract the temp value or mean temp value.

Thank you

Regards

Michea

[psosnows]

Hi Mechea,

first I have to clear one thing. IOobject is just a "tool" which allows you to read and write files. By creating IOdictionary you get access to some kind of data structure which is associated with a file. This means, that all the time you operate on a file that is stored on a hard drive. This is not a way to manage work data.

I do not get the need of grouping all properties under one label. I usually simply call the properties like: fluidRho, fluidK, solidRho, solidK, etc. In the end, you always need to call the "name" of a property, so why should one complicate the structure of data?

If you want to store them in more organized fashion, create a structure or a class that will gather them, or if you like remembering numbers, you can store them in a list or queue (this may be a good way to store the coefficients of a polynomial).

Regarding the polynomials. What do you mean by "define the one variable as a function of T". You can do on paper, sure. But forcing the solver to apply this assumption requires an algorithm in the code. First read coefficients before starting the loop and store them in a clear fashion, create a function that will calculate the polynomial, calculate the value at each time step at proper moment in the main loop, etc. Maybe there are some ready-to-use and well-described classes that do this stuff. But if you can not find them, you will have to write them yourself or pay someone to do that, sorry

Good luck with the code!

[menorka]

Great thread and a special thanks to Pawel for patiently explaining the details of the cht-case!

I'm trying to make a very simple 2d model to get the hang of things. Three rectangular solid domains sitting in a hot fluid domain with flow from the bottom to the top. I want to see how the solids heat up.

I started out with the tutorial case and built from there. I though I got it figured out but my case wouldn't run. Reading through the log files it seems to work fine up until I call the solver.

--> FOAM FATAL IO ERROR: 
cannot open file

file: /home/linus/menorka/0.001/fluid/p at line 0.

    From function regIOobject::readStream()
    in file db/regIOobject/regIOobjectRead.C at line 62.

FOAM exiting

No p-file is created. In fact no pressure, no velocity, no nothing. So the problem must be earlier right? But I can't find any clues in the log-files. Could someone please have mercy on me and give it a quick check?

[psosnows]

Hi menorka,

I looked through your case, unfortunately I can not name what is exactly wrong. But here are some hints that may be helpful:

First some general remarks about the script in the tutorial.
At the beginning you have one, big case with one big mesh. You "select" groups of cells (the sets and fields) and you divide this big mesh into pieces, which are saved in 0.001 folder. This approach is some kind of adaptation of mesh-varying-in-time cases. Summing up in points:

1) You start with:
- system folder with 3 standard files and some decompose/zone control files;
- constant folder with polyMesh folder in it and some properties files/folders;
- 0 folder with data files in it (note that there is no division into regions here!);
2) You run the script without solver and get:
- system folder with region folders in it;
- constant folder with region folders with some properties (note that those region folders do not contain polyMesh in them!)
- 0.001 folder with separated data and polyMesh folders;
3) when you run chtMultiRegionFoam you work on:
- mesh that is stored in 0.001 subfolders;
- initial data that is stored in 0.001 folder (you can even delete 0 folder);
- properties that are stored in region subfolders in constant;
- fvS* files in subfolders of system (other two in system can be deleted);
- controlDict in system folder;
4) post-processing:
- you can "paraFoam -touch -region X" all things, but I am not sure if you do not need to have polyMesh in each time folder...
- you can convert to VTK (loose a lot of memory).

In the end, I found it too complicated, easily-error creating, hard with mesh and initial data handling...
Of course you save a lot of time, since you do not have to create 4 separate meshes and they are simply generated (and your fluid mesh will be a bit painful in blockMesh).

In your case, I think you simply do not have initial data in 0 folder, so the script can not decompose those fields to parts.

If I were you, I would do this case like this (it works for my problems fine):
- treat the case that you have as a scrapyard from which you will build up a work case (I will call it TMP);
- create "raw" work case: standard 0, constant, system folders (call RUN);
- in each of standard folders in RUN create "region" subfolders;
Now we build up our case. Copy:
- controlDict to system;
- fvS* files to each subfolder in system;
- regionProperties to constant;
- any files in TMP's constant subfolders to corresponding subfolders in RUN's constant;
- polyMesh from TMP's 0.001 subfolders to corresponding subfolders in RUN's constant;
- all data files from TMP's 0.001 subfolders to corresponding subfolders in RUN's 0;
- worst part, check each boundary file in RUN if the names are different for coupled patches, and if they are the right type (directMappedPatch, explained earlier in the thread)
- check all data files if all boundaries are mentioned. If not, fix it

After doing that, you get a nice OF case: all constant things (like mesh, props) are in constant folder, all initial data are in 0, all simulation control are in system.
It should run smoothly like a summer breeze
For post processing use the "paraFoam -touch -region <X>" trick.

Hope it helps you a bit
Best,
Pawel

ps
Of course you can do things like in tutorial. In my case, after some time I simply got fed up and thought that it is better to do something slower and less automatic, but with understanding of everything, than to go with a ready code... But probably I am just strange