[mturcios777]

Downloaded the latest release through the git repository and these all appear to be missing. Is this just me, and if not why are they gone?

[mturcios777]

Figured I'd answer my own question so if people stumble on this thread they can get information, and to continue the discussion begun in this thread (apologies in advance for the long post). The dieselSpray class has been deprecated by including its functionality into the generalized lagrangian spray libraries. This happened in OF 2.0.x: New Langrangian Functionality, look at the subsection "Migration of DieselSpray"

The new lagrangian spray classes are used in the solvers like:
reactingParcelFoam
sprayFoam
sprayEngineFoam

Currently they are formulated to only have one spray, via the constructor (in this case, for sprayFoam)

Info<< "\nConstructing reacting cloud" << endl;
basicSprayCloud parcels
(
    "sprayCloud",
    rho,
    U,
    g,
    slgThermo
);

When running a case, there needs to be a dictionary called sprayCloudProperties in the constant directory that describes the spray. Currently it appears the solver can only use one spray. It may be possible to use more by something like:

 scalar sprayNum(readScalar(controlDict.lookup("sprayNum")));
PtrList<basicSprayCloud> sprays(sprayNum);

forAll(sprays,sprayI)
{
    OStringStream num;
    num << i;
    word sprayName = "sprayCloud" + num.str();
    sprays.set
    (
        sprayI,
        new basicSprayCloud
        (
            sprayName,
            rho,
            U,
            g,
            slgThermo
        )
    );
}

I used some of Niklas's code from this thread. Now you need a series of files called sprayCloud0Properties, sprayCloud1Properties, ..., sprayCloud{n-1}Properties. Maybe this could be pushed into the main solver, or another solver like multiSprayFoam? Also, there needs to be a step where you add up all the source terms for transport equation solving, for rhoEqn.H for example

fVScalarMatrix rhoSource; //I'm not sure how to initialize this. Can I make this a volumeScalarField?

forAll(sprays,i)
{
    rhoSource+= sprays[i].Srho(rho); //I think this should be right, but not 100%
}

{
    solve
    (
        fvm::ddt(rho)
      + fvc::div(phi)
      ==
        rhoSource
    );
}

All sprays will use the same slgThermo, and not knowing enough about this new way of doing this I don't know if this is desirable or not. Please comment and let me know if anything in here is wrong or inefficient and I'll get some tests run.

[mturcios777]

Before that though, it appears that there may be a bug in sprayFoam (and by extension reactingParcelFoam as the transport equations all originate there). In the included aachenBomb tutorial case, injection or the parcels works, though it appears that only N2 is displaced; the O2 field remains uniform at 0.234. Can someone verify this behaviour independently?

EDIT: I've confirmed this behaviour on two different machines, seems the change occured in OF2.1x. I've filed a bug report, I'll look though the solver and lagrangian libraries and see if I can come up with anything useful.

[niklas]

Yeah, I saw the bug-report this morning and the problem was in the Make/options file.
Seems like the order of the includes was wrong so it picked up the rhoEqn from the
wrong place (this didnt have a source term for the evaporation).

solution is to place the
-I$(FOAM_SOLVERS)/lagrangian/reactingParcelFoam \

at the first position.
cheers,
N

[mturcios777]

Thanks Niklas, it works perfectly now! I have a question that you may be able to answer. In my solver I am keeping track of a conserved scalar whose source term comes from the evaporation of a species in the spray. If I have the index of the species (iC7H16), I used to be able to add the following to the transport equation:

 solve
{
//transport with the usual advection/diffusion terms
==
dieselSpray.evaporationSource(iC7H16)
}

With the change in the libraries, I thought the equivalent call for a basicSprayCloud would be

 volScalarField& beta = Y[iC7H16];

solve
{
//transport equation has the usual advection/diffusion terms
==
parcels.SYi(iC7H16,beta)
}

The code compiles, but at runtime I get the error:

--> FOAM FATAL ERROR: 
incompatible fields for operation 
    [beta] == [C7H16]

    From function checkMethod(const fvMatrix<Type>&, const fvMatrix<Type>&)
    in file /home/mturcios/OpenFOAM/OpenFOAM-2.1.x/src/finiteVolume/lnInclude/fvMatrix.C at line 1300.

It seems there is some more consistency checking going on (which I guess is good), but I'm not sure how to work around this without breaking Foam. Any suggestions? Maybe I need to cast the returned function as a generic source term? Thanks in advance!

[niklas]

the parcel.SYi is no longer just a source term, but a fvScalarMatrix.
Thats why you can't just add it anymore, since it actually checks that
you are adding apples with apples.
That means you also can make the source a mix of explicit/implicit, by the coefficient
in the sourceTerms dictionary.

To extract the source part, ie. the explicit part you can do something like this

    volScalarField parcelSource
    (
        IOobject
        (
            "parcelSource",
            mesh.time().timeName(),
            mesh,
            IOobject::NO_READ,
            IOobject::NO_WRITE
        ),
        mesh,
        dimensionedScalar("zero", dimMass/dimTime/dimVolume, 0.0)
     );

    fvScalarMatrix parcelEq(parcels.SYi(i, Yi));
    scalarField source(parcelEq.source());
    parcelSource.internalField() = source;

and then add parcelSource to the transport equation 'as usual'

[mturcios777]

Many thanks Niklas! To tie up the questions in this thread, how should multiple injectors be handled under the new lagrangian libraries. For immediate consideration I have two sprays which isn't hard to implement manually (i.e., include each spray explicitly in the transport equations), but for more than that a fully general one would be very nice. Or have I misunderstood the library/solvers and is the the ability to have multiple injectors already present?

[niklas]

No its not possible at the moment.

But when you say multiple injectors, do you actually mean that or just multiple
injection positions.

Because there is a slight difference, since the latter is possible and pretty straightforward.
Just add a multipleInjectors injector.

The problem with doing it the way you describe is that there will be no interaction
between the different 'injectors', so if you want to have collisions and let the
parcels exchange mass, its not possible.

I've talked to Andy about this and he has an idea how he wants to do it, but he hasn't added the feature yet.

[mturcios777]

Both actually. I see what you mean about the interaction problem. Right now it isn't a huge problem as I don't *need* droplet interaction that much (and the old dieselSpray library still compiles under OF21x for when we go), but it would be nice to migrate to this new completely general formulation, and plus the ddtPhiCorr method for dynamic meshes will become much more important to us as we move forward.

I'm testing out the code I posted earlier and it works ok so far. I'm working on getting behavior similar to the old commonRailInjector, but since all my questions have been answered from this thread I'll start a new one and link to it: here it is.

[mturcios777]

The code posted by Niklas works very well. While rooting around the new lagrangian libraries while contemplating multiple injectors, I noticed the following class ReactingLookupTableInjection, which looks like it does multiple injection sites, albeit with a much more manual approach. Could this be adapted to give multiple injectors?

[Abhishekd18]

Hi,

I am facing problem with dieselFoam 1.6 ext. I am getting janaf error. Temperature in some of the cells drops below 200. These cells are located where there is injection. So, I think it may be due to droplets absorbing excessive heat from surrounding. I tried reducing max Courant number to 0.01 and started with very less time step. I also tried with finer mesh. Still, I am not able to get rid of the error.

However, the same setup with same boundary conditions works perfectly fine with OpenFoam 2.0.

Can anyone help me on this?

[amfortas]

Hi Abhishek,

I am facing the same problem with 1.6-ext. After a while searching I found that there are a bug:

http://sourceforge.net/apps/mantisbt...view.php?id=46

which is still unresolved.
I am working actually with OF-1.5-dev which also includes some dynamic mesh features.

Alex