View Issue Details

IDProjectCategoryView StatusLast Update
0000837OpenFOAMBugpublic2015-02-05 09:20
Reporteruser331Assigned Tohenry  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionno change required 
PlatformLinuxOSOpenSUSEOS Version12.2
Summary0000837: sprayEngineFoam broken with last update to lagrangian
DescriptionI was testing a case with sprayEngineFoam with a custom solver based on sprayEngineFoam that crashes on the start of liquid injection. To ensure I wrote my solver properly, I ran the case again with sprayEngineFoam with similar injection parameters. I get the following error:

Courant Number mean: 1.02494632e-05 max: 0.00465584598
deltaT = 9.50481277e-09
Crank angle = 349.00043 CA-deg
deltaZ = 2.41768611e-08
clearance: 0.0120415656
Piston speed = 2.54364412 m/s

Solving cloud sprayCloud

--> FOAM FATAL ERROR:
Not implemented

    From function Foam::scalar Foam::liquidProperties::pv(scalar, scalar) const
    in file liquidProperties/liquidProperties.C at line 230.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so"
#2 Foam::liquidProperties::pv(double, double) const in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/libliquidProperties.so"
#3 Foam::LiquidEvaporation<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > >::TMax(double, double) const in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/liblagrangianSpray.so"
#4
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#5
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#6
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#7
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#8
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#9
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#10
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#11
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#12
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#13
 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam"
#14 __libc_start_main in "/lib/libc.so.6"
#15
 at /home/abuild/rpmbuild/BUILD/glibc-2.15/csu/../sysdeps/i386/elf/start.S:122
Aborted
 
Steps To ReproduceRun any sprayEngineFoam case with liquid injection
Additional InformationI have included my sprayCloudProperties, in case there is an issue with the configuration (doubtful as I've cross checked it with the new aachenBomb tutorial). sprayFoam appears to work, so it may be an issue with the engine versions.
TagsNo tags attached.

Activities

user331

2013-05-06 19:19

 

sprayCloudProperties (4,694 bytes)   
/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.2.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      binary;
    class       dictionary;
    location    "constant";
    object      SprayCloudProperties;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

solution
{
    active          true;
    coupled         true;
    transient       yes;
    cellValueSourceCorrection on;

    sourceTerms
    {
        schemes
        {
            rho             explicit 1;
            U               explicit 1;
            Yi              explicit 1;
            h               explicit 1;
            radiation       explicit 1;
        }
    }

    interpolationSchemes
    {
        rho             cell;
        U               cellPoint;
        thermo:mu       cell;
        T               cell;
        Cp              cell;
        p               cell;
    }

    integrationSchemes
    {
        U               Euler;
        T               analytical;
    }
}

constantProperties
{
    T0              320;

    // place holders for rho0 and Cp0 - reset from liquid props using T0
    rho0            1000;
    Cp0             4187;

    youngsModulus   1e9;
    poissonsRatio   0.35;

    epsilon0        1;
    f0              0.5;
    Pr              0.7;
    Tvap            273;
    Tbp             373;

    constantVolume  false;
}


subModels
{
    particleForces
    {
        sphereDrag;
    }

    injectionModels
    {
        model1
        {
            type            coneNozzleInjection;
            SOI             349;
            massTotal       1.4e-06;
            parcelBasisType mass;
            injectionMethod disc;
            flowType        pressureDrivenVelocity;
	        Pinj	    300e5;
            outerDiameter   1.3e-4;
            innerDiameter   0;
            duration        4;
            position        (0.001200 0.000000 -0.00222);
            direction       (1.0 0.0 -0.325);
            parcelsPerSecond 20000000;
	        flowRateProfile table
            (
                (0 0)		 
                (0.5 0.5)
                (1.0 1)
                (3 1)
                (3.5 0.5) 
		        (4 0)
            );

            Cd              constant 0.9;

            thetaInner      constant 0.0;
            thetaOuter      constant 20.0;

            sizeDistribution
            {
                type        RosinRammler;

                RosinRammlerDistribution
                {
                    minValue        1e-06;
                    maxValue        0.00015;
                    d               0.00015;
                    n               3;
                }
            }
        }
    }

    dispersionModel none;

    patchInteractionModel standardWallInteraction;

    heatTransferModel RanzMarshall;

    compositionModel singlePhaseMixture;

    phaseChangeModel liquidEvaporation;

    surfaceFilmModel none;

    atomizationModel none;

    breakupModel    ReitzDiwakar; // ReitzKHRT;

    stochasticCollisionModel none;

    radiation       off;

    standardWallInteractionCoeffs
    {
        type            rebound;
    }

    RanzMarshallCoeffs
    {
        BirdCorrection  true;
    }

    singlePhaseMixtureCoeffs
    {
        phases
        (
            liquid
            {
                C7H16               1;
            }
        );
    }

    liquidEvaporationCoeffs
    {
        enthalpyTransfer enthalpyDifference;

        activeLiquids    ( C7H16 );
    }

    ReitzDiwakarCoeffs
    {
        solveOscillationEq yes;
        Cbag            6;
        Cb              0.785;
        Cstrip          0.5;
        Cs              10;
    }

/*
    ReitzKHRTCoeffs
    {
        solveOscillationEq yes;
        B0              0.61;
        B1              40;
        Ctau            1;
        CRT             0.1;
        msLimit         0.2;
        WeberLimit      6;
    }
*/
    TABCoeffs
    {
        y0              0;
        yDot0           0;
        Cmu             10;
        Comega          8;
        WeCrit          12;
    }
}


cloudFunctions
{}


// ************************************************************************* //
sprayCloudProperties (4,694 bytes)   

user331

2013-05-07 22:39

  ~0002178

Just tried it with sprayFoam and can confirm it crashes there, so it isn't just the engine version. Also tried different flow rate models and still crashed.

user2

2013-05-08 08:56

  ~0002179

So far I cannot reproduce your error using a similar setup for the sprayFoam aachenBomb case - can you provide a small test case?

user331

2013-05-08 18:17

  ~0002182

Weird, after a complete rebuild from scratch it is working, albeit now hanging after some parcel injection. I've seen some messages on the forums addressing this, so I'll keep working on it.

user331

2013-05-09 17:27

  ~0002184

I've uploaded a simple case that seems to indicate that there is an issue with the timing of injection. Its a simple cylinder mesh, using the injection profile from the aachenBomb case (with the engine RPM and time adjusted to give the same injection duration in real time.

The log file shows that injection doesn't begin at the stated SOI, and there are problems integrating the profile. I've seen that other cases with similar timing work if we add 360 degrees (so the negative may have something to do with it).

I remember that there was a bug in 2.1.x with spray models and engine time. Is this a possible resurrection?

user331

2013-05-09 17:27

 

log.dat (675,281 bytes)   

user331

2013-05-09 17:28

 

user331

2013-05-09 17:28

 

plainCylinder.tar.gz (12,147 bytes)

user331

2013-05-10 23:22

 

user331

2013-05-10 23:26

  ~0002187

Ok, so I updated the case because there was a problem with the engine speed and spray location (its been a long week, apologies for the rapid changes), there are still issues with spray injection.

user2

2013-05-13 11:34

  ~0002190

The problem relates to the handling of your table - the duration is specified as 12.5 CA, but during the calculation, it is queried outside of this range by 1 time step. At the moment, bounds handling is not included in the table functionality = error

We will look to include the bounds handling in the future (quicker with sponsorship), but as an interim work-around, extend your table to fully include the end of injection, e.g. by adding:

    ...
    (0.0012501e4 0)
    (1000 0)

user331

2013-05-16 21:24

  ~0002215

Thanks Andy. Your suggestion fixed the issues with the tables, but I still get hanging when injection starts. I've asked for some help on the forums, and it appears this might be a machine specific problem:

http://www.cfd-online.com/Forums/openfoam-solving/117821-sprayenginefoam-problems-2-2-x.html

Have there been any reports of problems with lagrangian sprays under OpenSUSE?

user2

2013-05-20 09:41

  ~0002219

> Have there been any reports of problems with lagrangian sprays under OpenSUSE?

not that we're aware of

have you tried attaching gdb to the process ID (XXX) and seeing where the code appears to be hanging? i.e.

  $ gdb -pid XXX
  $ where

user331

2013-05-21 18:46

  ~0002229

Here is the gdb output. I think there is an issue with the particle tracking:

(gdb) where
#0 0x080c1614 in __x86.get_pc_thunk.bx ()
#1 0x080d0ea6 in Foam::max<Foam::Vector<double>, double, 3> (vs1=..., vs2=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/VectorSpaceI.H:445
#2 0xb34c12a1 in Foam::treeDataCell::calcCellBb (this=0xb28f138, cellI=10951) at algorithms/indexedOctree/treeDataCell.C:63
#3 0xb34c1712 in Foam::treeDataCell::overlaps (this=0xb28f138, index=10951, cubeBb=...) at algorithms/indexedOctree/treeDataCell.C:163
#4 0xb625cfce in Foam::indexedOctree<Foam::treeDataCell>::divide (this=0xb28f138, indices=..., bb=..., result=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:148
#5 0xb625b193 in Foam::indexedOctree<Foam::treeDataCell>::divide (this=0xb28f138, bb=..., contents=..., contentI=154) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:193
#6 0xb625b55a in Foam::indexedOctree<Foam::treeDataCell>::splitNodes (this=0xb28f138, minSize=10, nodes=..., contents=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:274
#7 0xb6259c6f in Foam::indexedOctree<Foam::treeDataCell>::indexedOctree (this=0xb28f138, shapes=..., bb=..., maxLevels=8, maxLeafRatio=10, maxDuplicity=5) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:2534
#8 0xb33c8ee0 in Foam::polyMesh::cellTree (this=0x9260d58) at meshes/polyMesh/polyMesh.C:913
#9 0xb33ca3d5 in Foam::polyMesh::findCellFacePt (this=0x9260d58, pt=..., cellI=@0xbf8077f4: -1, tetFaceI=@0xbf8077f0: -1, tetPtI=@0xbf8077ec: -1) at meshes/polyMesh/polyMesh.C:1238
#10 0xb503714d in Foam::InjectionModel<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::findCellAtPosition (this=0xa1d95b0, cellI=@0xbf8077f4: -1, tetFaceI=@0xbf8077f0: -1, tetPtI=@0xbf8077ec: -1, position=..., errorOnNotFound=false) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/InjectionModel.C:115
#11 0xb505a561 in Foam::ConeNozzleInjection<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::setPositionAndCell (this=0xa1d95b0, position=..., cellOwner=@0xbf8077f4: -1, tetFaceI=@0xbf8077f0: -1, tetPtI=@0xbf8077ec: -1) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/ConeNozzleInjection.C:351
#12 0x08127adb in Foam::InjectionModel<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::inject<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xa1d95b0, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/InjectionModel.C:537
#13 0x08113f45 in Foam::InjectionModelList<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::inject<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xbf808b6c, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/InjectionModelList.C:187
#14 0x0810053b in Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > >::evolveCloud<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xbf8087bc, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:188
#15 0x080e8c5e in Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > >::solve<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xbf8087bc, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:100
#16 0x080d4c19 in Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > >::evolve (this=0xbf8087bc) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/spray/lnInclude/SprayCloud.C:235
#17 0x080c33d9 in main (argc=1, argv=0xbf809e94) at sprayEngineFoam.C:81

user331

2013-06-25 17:32

  ~0002293

Just a quick update. The problem continues, with the only relief coming from reducing the timestep dramatically. The conditions at injection are similar to the aachenBomb case, and there have been reports that the injection works fine on other machines. Still trying to figure out what may be the problem.

user331

2013-08-09 17:43

  ~0002387

I have just installed both OpenSUSE 12.2 and Ubunutu 12.04 LTS on the same machine and can confirm the injection does not hang on Ubuntu but does on OpenSUSE. There is some underlying issue with the base libraries. I will see if this has been resolved in the newest OpenSUSE in the coming weeks.

dkxls

2013-08-09 22:24

reporter   ~0002388

I don't think this is directly related to OpenSUSE vs. Ubuntu.

There have been bugs in the Lagrangian spray library and your initial error message was definitely related to them (the TMax error). These bugs were resolved today (git commit b592ac38bfcd73383ae4eac77c78c64cee93af34), hence you need a recent 2.2.x git-checkout. I would be happy if you could test the new code.

A note on OpenSUSE: We are using OpenSUSE for years (currently 12.2) and haven't had any distribution specific problem.

user331

2013-08-09 22:57

  ~0002389

I know, this is very odd. I installed both OS's on the same machine (clean install) and a fresh install of OpenFOAM 2.2.x (through the repository). Even before the recent commits, running the case in the thread above would hang in OpenSUSE and be fine in Ubuntu (including the custom engine solver). After pulling the newest commit and rebuilding everything, OpenSUSE still hangs. It might be a weird confluence of architechture, libraries or something. I think it will remain one of those unsolved mysteries.

dkxls

2013-08-10 12:06

reporter   ~0002391

Well after all there are differences between distribution, I just wouldn't have expected that OF will run into problems because of that. This is indeed really odd.
Maybe one more question: How do you install "OF through the repository" on OpenSUSE? Do you mean a git checkout and compiling it on your machine?

user331

2013-08-12 17:02

  ~0002392

Yes, I am installing the git repository and compiling, as I have a few custom solvers and boundary conditions I need for my simulations.

wyldckat

2013-08-13 20:17

updater   ~0002400

@mturcios: Can you share the information about which versions of the GNU compiler/linker applications you're using for building OpenFOAM 2.2.x? Namely, the versions given by the following commands:

gcc --version
g++ --version
ld --version


because it's possible that you might be using conflicting versions on openSUSE or that you might be using the "gold" version of "ld"... although AFAIK, it should not have worked with "gold"...

user331

2013-08-13 20:22

  ~0002401

Thanks Bruno. Here are the results of the commands you specified:

gcc --version:
gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773]

g++ --version:
g++ (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773]

ld --version:
GNU ld (GNU Binutils; openSUSE 12.2) 2.22

user331

2013-08-14 19:55

  ~0002412

An additional note, lagrangian injection hangs for sprayFoam and sprayEngineFoam on OpenSUSE 13.2 as well. This is after a clean install of the OS along with rebuilding OpenFOAM 2.2.x from repository and using the same case files that worked perfectly in Ubunutu 12.04 LTS.

Very bizarre errors here. I think we may be switching to Ubuntu LTS for this reason as well as the long term stability.

wyldckat

2013-08-14 21:55

updater   ~0002414

@Marco: I'm using the case attached named "plainCylinder.fixed.tar.gz" on the latest OpenFOAM 2.2.x, built on Ubuntu 12.04 x86_64, with Gcc 4.6.3.
To run it, I used the commands:
  blockMesh
  foamJob sprayEngineFoam

and am monitoring the file "log" to check if everything is running or not.

I went back to read the whole history of this bug report and I can't figure out what I should be looking for exactly. When/where exactly does the solver hang in openSUSE?

user331

2013-08-14 22:58

  ~0002415

At around -14.35 CA, the solver gets to the "Solving cloud sprayCloud" line and mentions the parcels (usually less than 10), after which the solver hangs. No crash or error message, it just stays at that line.

wyldckat

2013-08-15 01:13

updater  

wyldckat

2013-08-15 01:33

updater   ~0002416

Last edited: 2013-08-15 11:19

Attached is the case "plainCylinder.fixed2.tar.gz", which is based on "plainCylinder.fixed.tar.gz", with the following adjustments:
 - the field "alphat" should use "compressible::alphatWallFunction", because it was enforced as such in one of the somewhat recent 2.2.x commits;
 - as Andy indicated a few comments above, I added these two lines:
    (0.0012501e4 0)
    (1000 0)
  to "constant/sprayCloudProperties", in the table "subModels.injectionModels.model1.flowRateProfile".

As I wrote above, I used the following two commands to run the case:
  blockMesh
  foamJob sprayEngineFoam


I've tested in a virtual machine with openSUSE 12.3 x86_64, with the latest OpenFOAM 2.2.x (commit 0afc56c40d89e253fa2f5d7c5267c73aac548b69), using 2 different builds:
 - One where the default compiler choice is left as-is, namely: WM_COMPILER=Gcc
 - Another where the compiler chosen is more related to openSUSE's version: WM_COMPILER=Gcc47

More specifically, I used the following aliases for sourcing the desired environments:

  alias of22x47='source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc WM_NCOMPPROCS=4 WM_MPLIB=SYSTEMOPENMPI WM_COMPILER=Gcc47'
  alias of22x='source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc WM_NCOMPPROCS=4 WM_MPLIB=SYSTEMOPENMPI'


My bet was on the issue being that the default compiler options were giving the problems, but I was not able to reproduce the same problem.
In addition, both runs did not go through the "-14.35 CA" position, they simply did "-15 CA" and "-14 CA", and in neither one of these two angles were introduced new parcels.


So my suggestions for now are as follows:
1- Test with this case I attached, to so that you can confirm if the same problem still occurs on your machine with openSUSE.

2- If it still happens, try using the "Gcc47" compiler option, as indicated above, or simply hack directly the "etc/bashrc" file and then start a new terminal and build OpenFOAM again.


Because from everything else, the only remaining ideas that come to mind are:
 a) The solver you've created might be entangled with OpenFOAM's own core code, which leads to this problem.
 b) There could be a hardware-kernel problem, namely something in the kernel on openSUSE is not controlling properly your machine, while Ubuntu has everything under control.

user4

2013-08-15 09:02

  ~0002418

Re a) : from the traceback of your injection it seems to hang in the octree construction routines (using in finding cells). There are always potential numerical precision issues with any decision made based on floating point numbers so it might be that you've hit a corner case.

- check that your injection location is well inside a cell and also not exactly at the middle of the domain in any component.
- perturb your injection location and/or mesh slightly and see if this helps
- is your geometry 2D? If so can you make it 'thicker' to be more cube like.

dkxls

2013-08-15 09:37

reporter   ~0002419

On the compiler issue: OpenSUSE uses gcc4.7 as default compiler for 12.2 and 12.3.
I wouldn't even know where to get another version from, except of the ancient gcc3.3 packages and compiling gcc from source.

wyldckat

2013-08-15 11:23

updater   ~0002420

@dkxls: gcc 4.7 should work well with OpenFOAM. What I was talking about is the compiler options. To see what I mean, run these commands:
  foam
  diff -Nur wmake/rules/linux64Gcc wmake/rules/linux64Gcc47

It will show you the few differences there are in the compilation options that are used for building OpenFOAM, depending on the WM_COMPILER environment variable+options that I mentioned.

user331

2013-08-15 16:52

  ~0002421

Last edited: 2013-08-15 17:24

@wyldkat: I'm sorry, I forgot to mention that I changed the SOI to be -14.5 to see the results sooner. The other changes you made (alphat->compressible::alphat and the injection profile) I had also implemented. Still same result. As far as hardware, it may be possible since both machines this has happened on are Intel (one is a Xeon, the other is a P4 we had lying around). I don't think the custom solver is entangling with the core one, as I am running sprayEngineFoam as a test before I even compile my solver.

Thanks everyone for your help; it seems like this is a case where we may never get the straight answer, and the effort involved to track it down is not worth it. I'll revisit this every now and again, but at this time switching to Ubuntu seems the best fix available.

Issue History

Date Modified Username Field Change
2013-05-06 19:19 user331 New Issue
2013-05-06 19:19 user331 File Added: sprayCloudProperties
2013-05-07 22:39 user331 Note Added: 0002178
2013-05-08 08:56 user2 Note Added: 0002179
2013-05-08 08:56 user2 Priority immediate => normal
2013-05-08 18:17 user331 Note Added: 0002182
2013-05-09 17:27 user331 Note Added: 0002184
2013-05-09 17:27 user331 File Added: log.dat
2013-05-09 17:28 user331 File Added: logSummary.-180.dat
2013-05-09 17:28 user331 File Added: plainCylinder.tar.gz
2013-05-10 23:22 user331 File Added: plainCylinder.fixed.tar.gz
2013-05-10 23:26 user331 Note Added: 0002187
2013-05-13 11:34 user2 Note Added: 0002190
2013-05-16 21:24 user331 Note Added: 0002215
2013-05-20 09:41 user2 Note Added: 0002219
2013-05-21 18:46 user331 Note Added: 0002229
2013-06-25 17:32 user331 Note Added: 0002293
2013-08-09 17:43 user331 Note Added: 0002387
2013-08-09 22:24 dkxls Note Added: 0002388
2013-08-09 22:57 user331 Note Added: 0002389
2013-08-10 12:06 dkxls Note Added: 0002391
2013-08-12 17:02 user331 Note Added: 0002392
2013-08-13 20:17 wyldckat Note Added: 0002400
2013-08-13 20:22 user331 Note Added: 0002401
2013-08-14 19:55 user331 Note Added: 0002412
2013-08-14 21:55 wyldckat Note Added: 0002414
2013-08-14 22:58 user331 Note Added: 0002415
2013-08-15 01:13 wyldckat File Added: plainCylinder.fixed2.tar.gz
2013-08-15 01:33 wyldckat Note Added: 0002416
2013-08-15 09:02 user4 Note Added: 0002418
2013-08-15 09:37 dkxls Note Added: 0002419
2013-08-15 11:19 wyldckat Note Edited: 0002416
2013-08-15 11:23 wyldckat Note Added: 0002420
2013-08-15 16:52 user331 Note Added: 0002421
2013-08-15 16:54 user331 Note Edited: 0002421
2013-08-15 17:24 user331 Note Edited: 0002421
2015-02-05 09:20 henry Status new => closed
2015-02-05 09:20 henry Assigned To => henry
2015-02-05 09:20 henry Resolution open => no change required