[simpomann]

Hi there,

I implement the following BC instead of fixedValue 1:

    inlet
    {
        type            uniformFixedValue;
    uniformValue     table 
    (
      (  0   1)
      ( 0.01 1)
      (0.1  1)
    ); 
    }

What I get in the interfoam-log:

[0] 
[0] 
[0] --> FOAM FATAL ERROR: 
[0] object is not allocated
[0] 
[0]     From function const T& Foam::autoPtr<T>::operator()() const
[0]     in file /home/preston2/mattijs/rpmbuild/BUILD/OpenFOAM-2.1.0/src/OpenFOAM/lnInclude/autoPtrI.H at line 132.
[0] 
FOAM parallel run aborting

Who is mattijs?
I think there is a small bug in there but as I dont really need this boundary I dont investigate further.
It's openFoam 2.1.0 with parallel interfoam.
Sorry if it is already fixed, I had a look in the bug reporting system but I am super busy so maybe I overlooked it.

Greetings,

Simon

[wyldckat]

Greetings Simon,

Since you wrote that you were busy, I've made a test case and checked with the latest 2.1.x and the error does still occur. The report has been made here: http://www.openfoam.org/mantisbt/view.php?id=709

edit: And 1h later it's already fixed!

Best regards,
Bruno

[simpomann]

Hey,

Thanks for cleaning it up!
I am not sure if it is related, but when I put a flowRate with time-table for U condition in the same case, it crashes as well (interFoam, 2.1.0, parallel).
Well if I find the logfile somewhere I put it in here. Just about to finish my thesis, things go crazy here.

Greetings,

Simon

[wyldckat]

Hi Simon,

I've tested in the tutorial "multiphase/interFoam/laminar/damBreak" to modify in the "0/U" file the "leftWall" entry to this:

    leftWall
    {
        type        flowRateInletVelocity;
        flowRate    0.02;        // Volumetric/mass flow rate [m3/s or kg/s]
        value       uniform (0 0 0); // placeholder
    }

Then run with these commands:

blockMesh
cp 0/alpha1.org 0/alpha1
setFields
decomposePar
foamJob -s -p interFoam

And it ran with no problems, but only when I used OpenFOAM 2.1.x.
With 2.1.1, it was complaining about some "adjoint" thingy when running decomposePar, which is (probably) already fixed in 2.1.x.

Maybe the force be with you to finish the PhD on time!

Best regards,
Bruno