Hi, I have decomposed my prob
 

Hi,
I have decomposed my problem onto 4 processors. This works fine. Solving the equations works fine also, but when I try to reconstruct I run into the following problem:
h04n05:~>reconstructPar . base -time 0.001
/*---------------------------------------------------------------------------*\
| ========= | |
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \ / O peration | Version: 1.0.2 |
| \ / A nd | Web: http://www.openfoam.org |
| \/ M anipulation | |
\*---------------------------------------------------------------------------*/

Exec : reconstructPar . base -time 0.001
Date : Mar 08 2005
Time : 09:52:58
Host : h04n05.pdc.kth.se
PID : 27978
Root : /afs/nada.kth.se/home/nada/marcok/PDC/expSonicOodles
Case : base
Nprocs : 1
Create database

Create mesh

Time = 0.001

Reconstructing FV fields

Reconstructing volScalarFields

T
Tzz
pmean
Tmean
e
muEff
rhomean


--> FOAM FATAL ERROR :

FOAM exiting

h04n05:~>

These are not the only fields I have written to file:
h04n05:~>ls base/processor0/0.001/
T Tmean Txx Tyy Tzz U Umean e k muEff nAveragingSteps.raw pmean rho rhomean time
h04n05:~>

The error message does not give much help. Please advice.

Looks to me like a bug in the
 

Looks to me like a bug in the error message + a problem with boundary conditions. Have you got any fancy b.c.-s in your case? Could you try some other case (lid-driven cavity) to see all is well with the setup and installation? Could you please list the boundary condition types in the rhomean field in the time step 0.001

In summary, looks like a foam problem and we need to investigate - any chance of getting the case?

Hrv

I had a look at the T(temperat
 

I had a look at the T(temperature) field and it looked like where the boundary is described:

boundaryField
{
inlet1
{
type fixedValue;
value uniform 298;
}
outside
{
type zeroGradient;
}
wall
{
type zeroGradient;
}
base
{
type zeroGradient;
}
procBoundary0to2
{
type processor;
value nonuniform List<scalar>
3039
(
297.698
297.55
297.358
....
)
;

}
procBoundary0to1
{
type processor;
value nonuniform List<scalar>
995
(
293.813
293.603
...

)
;

}
}

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


And the rho field looks like
boundaryField
{
inlet1
{
type fixedValue;
value uniform 5.82019;
}
outside
{
type pressureTransmissive;
pInf 0;
lInf 0;
value nonuniform List<scalar>
1015
(
5.66108
5.6583
...

)
;

}
wall
{
type zeroGradient;
}
base
{
type zeroGradient;
}
procBoundary0to2
{
type processor;
value nonuniform List<scalar>
3039
(
5.6822
5.61607
...
)
;

}
procBoundary0to1
{
type processor;
value nonuniform List<scalar>
995
(
3.20264
3.20065
...
)
;

}
}


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

for rhomean
boundaryField
{
inlet1
{
type fixedValue;
value uniform 5.82019;
}
outside
{
type pressureTransmissive;
pInf 0;
lInf 0;
value uniform 1.13013;
}
wall
{
type zeroGradient;
}
base
{
type zeroGradient;
}
procBoundary0to2
{
type processor;
value nonuniform List<scalar>
3039
(
5.02962
4.74368
..
)
;

}
procBoundary0to1
{
type processor;
value nonuniform List<scalar>
995
(
2.01781
2.01751
2.01766
...
)
;

}
}


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


I don't require rho as initial data and calculate it as:

Info<< "Calculating field rho\n" << endl;
volScalarField rho
(
IOobject
(
"rho",
runTime.timeName(),
runTime,
IOobject::NO_READ,
IOobject::AUTO_WRITE
),
mesh,
psi.dimensions()*p.dimensions(),
p.boundaryField().types()
);

rho == psi*p;

Does rho get the right processor b.c. this way?
Where do I mail the case?

Yup, reproduced it - the probl
 

Yup, reproduced it - the problem is the pressure transmissive b.c. I'll fix the bug and let you know.

Apologies for inconvenience,

Hrv

Currently the pressureTransmis
 

Currently the pressureTransmissive BC is only implemented for p and not rho and consequently only correct for trans-sonic codes solving for p not rho. That means you should only use the pressureTransmissive BC for sonicFoam, sonicFoamAutoMotion and sonicTurbFoam not rhopSonicFoam or rhoSonicFoam. We are developing a replacement for the last two which is nearing completion but more testing is necessary before release.

What about the incomplete erro
 

What about the incomplete error message - if I try non-existing nams for patch field types it seems to work OK. Hmm.

I have just tried decomposing
 

I have just tried decomposing and reconstructing cases including pressureTransmissive BCs with OpenFOAM-1.1 and it works fine. I have added quite a bit of new BC handling to this release which will fix many (but not all) of the problems relating to pre/postprocessing tools.

1.1 is ready for release but due to the VERY large number of downloads of the current version we are having to find a new server to release from. We hope it will go out later this week.

Non-existing (not linked-in) patchField types are currently automatically handled as a default type which was introduced so that all boundary types do not have to be linked into all post-processing utilities. This has proved very effective for this purpose but has the disadvantage that if a full definition of the BC is needed by the application but it is not linked it does not know. I am working on this issue.

Great! Thanks Henry, Hrv
 

Great!

Thanks Henry,

Hrv

Hallo everyone, I simulated
 

Hallo everyone,

I simulated the evaporation of single droplets of C7H16 in air (5 injectors inject 10 droplets each with a time difference of 1e-4 seconds). The difference between the simulated time steps is 1e-6 seconds. However I decided to reconstruct only every 10th time step, as it is detailed enough for evaluation.
The problem I have is that the development of the continuous phase (air) and of the dispersed phase (C7H16) doesn't fit together. After 100 simulated time steps the droplet was already heated up (from it's start value of 303K) by the surrounding air (from it's start value of 1500K) whereas the decrease of the air temperature doesn't follow soon but has an delay of 30 time steps in comparison to the development of the droplet temperature. That means that the droplet is heated up by the hot surrounding air but the air temperature decreases only 30 time steps later. This obviously doesn't make sense. This effect can also be seen when analysing the decreasing mass of the droplet and the increasing fuel vapour in the surrounding air.
If I reconstruct every simulated time step instead of every 10th, I don't get this problem.
The following two pictures show the decrease of the droplet mass (is denoted with "m" in the scale on the right side of the picture) and the fuel vapour in air(is denoted with "C7H16" in the scale on the right side of the picture) after 100 simulated time steps. In the first one every single time step was reconstructed. The evaporation process looks realistic. In the second one with every 10th time step reconstructed there is the mentioned delay of the fuel vapour and droplet mass decrease.

http://www.cfd-online.com/OpenFOAM_D...your_image.gif

http://www.cfd-online.com/OpenFOAM_D...your_image.gif

As reconstructing of every time step takes a lot of time and memory of my disc, I would like to restrict the reconstruction to only a small number of time steps (of cours without the mentioned problem from above).
Does anyone of you know why this problem arises? I would be very pleased to hear of you soon.

Thanks in advance,
Sebastian Vogl

I am sorry for uploading the p
 

I am sorry for uploading the pictures extra but I had to reduce the file size and I must upload them as .zip files.

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif t100_mTropfen_verdampfter_Kraftstoff_Umgebung_comp ressed.jpg.gz

http://www.cfd-online.com/OpenFOAM_D...hment_icon.gif t10_mass_droplet_evaporated_fuel_in_air_compressed .jpg.gz

Hallo again, I'm sorry for
 

Hallo again,

I'm sorry for begging again, but my problem is very serious.
Please take the time and think about it.

Sincerely,
Sebastian Vogl

Good Evening,

My reconstructPar collapsed suddenly! What happened! I did nothing!
A few minute ago, it works very well!

Here's error messages....help, please!

Mea culpa, I delete the "1e-5" directory which contains the non-zero boundary file. I apologize.