[Tom Lauriks]

Hi foamers,


I'm using simpleFoam to calculate the flow. I added a scalar with the functionObject scalarTransport.

scalarTransport works correctly (thanks to help from this forum). But when I try to apply a function object - surfaceFieldValue - to the field generated by scalarTransport (sf6), I'm getting the error message: Requested field sf6 not found in database and not processed. surfaceFieldValue is defined in the functions dict in controlDIct.

Does anyone know what is causing this problem?

[LuckyTran]

Same problem as before and same solution as before. sf6 is not a registered field name, it's available only to the scalarTransport object.

Put your function object for surfaceFieldVaue inside the scalarTransport.

If you want to avoid these limitations in the future. You can build your own solver by copying all the simpleFoam stuff. Go into createFields.H and add your sf6 field to the database.

[Tom Lauriks]

Thanks again for your answer. Before I posted this thread, I was thinking that this is the problem and tried what you said. It didn't work. I must, however, mention that I first ran the solver and then tried to obtain surfaceFieldValue by: simpleFoam -postProcess. I, just now, also tried running the solver again for 1 more step that is written out with surfaceFieldValue activated in scalarTransport. But I'm not getting any surfaceFieldValue output. Can this problem be fixed?

Thanks also for the suggestion on building my own solver. That might come in handy.

I'll include my scalarTransport dict (the patch side_back indeed exists):

sf6
{
type scalarTransport;
functionObjectLibs ("libsolverFunctionObjects.so");
enabled true;
writeControl outputTime;
log yes;
nCorr 1;
alphaD 0.62;
alphaDt 1.4286;
field sf6;
fvOptions
{
sf6
{
type scalarSemiImplicitSource;
active true;
scalarSemiImplicitSourceCoeffs
{
selectionMode cellSet;
cellSet source1;
volumeMode absolute;
injectionRateSuSp
{
sf6 (1e-2 0.0);
}
}
}
}
outletAverage
{
type surfaceFieldValue;
functionObjectLibs ("libfieldFunctionObjects.so");
enabled true;
writeControl timeStep;
//writeControl outputTime;//Doesn't make a difference

writeInterval 1;
log true;
writeFields true;
regionType patch;
name side_back;
operation areaAverage;
fields
(
sf6
);
}
}

[Tom Lauriks]

LuckyTran, I built the solver like you described. I then put the surfaceFieldValue dict outside the scalarTransport dict. It's super easy and works like a charm. That's a good enough solution for me.

For interested readers: in createFields.H, I copied and duplicated the code creating the p field and changed every p to the name of my field:
Info<< "Reading field sf6\n" << endl;
volScalarField sf6
(
IOobject
(
"sf6",
runTime.timeName(),
mesh,
IOobject::MUST_READ,
IOobject::AUTO_WRITE
),
mesh
);

[Tom Lauriks]

Maybe a small clarification: I was a bit reluctant to make my own solver, because I need to be able to run this case on our supercomputer. But compiling the new solver didn't cause any trouble. I just ran wclean and wmake in the map with the modified solver and the case ran without problems on our supercomputer.

[LuckyTran]

Good that you were able to build your custom solver.

Just FYI:
IOobject::MUST_READ means that OF will now throw a bitch fit if there isn't a sf6 file in your timedir (/0 or wherever). This is how you stop newbies from getting too far when they forget to provide file mandatory fields like p,U, etc.

For fields that are optional, you can choose to not make it required. The other options are READ_IF_PRESENT and NO_READ.

READ_IF_PRESENT means OF won't complain even if the file is not there (when you do not want to use your scalarTransport for example). Some fields are calculated as post processing fields only and never need to be read, in which case you can use NO_READ.

[Tom Lauriks]

Thanks again! This is very interesting info.