View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001266OpenFOAMBugpublic2014-04-10 16:312014-05-02 10:26
Reporteruser838Assigned Touser21 
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionno change required 
PlatformRed Hat Scientific Linux 6.4OSOtherOS Version6.4
Summary0001266: fvOptions doesn't work
DescriptionDear OF guys,

I'm using an fvOptions file to add a heat source [Watts/m3] to my system.

I'm using CHT multiregion foam and the heat source is being added to a solid region.

Although this fvOptions file is read when the solver is run, as confirmed by the log files in attachment (all the iterations except the last one are cut to keep the file small), it doesn't affect the result. Just as the heat source hadn't been applied at all.

The heat source applied has no effect on the result. If I try running two identical simulations one with and one without fv Options, the results are absolutely identical.
Steps To ReproduceCreate a geometry with two regions.

Use CHTmultiregion

Add fvOptions and specify a heat source to the solid (or to the fluid if you like?)

Run the case and verify that the results with and without fvOptions are the same
TagschtMultiregionFoam, fvOptions, Heat transfer

Activities

user838

2014-04-10 16:31

 

baffleTestCasefvOptions.zip (4,771 bytes)

user612

2014-04-14 08:20

  ~0003009

Please have a look at this bug: http://www.openfoam.org/mantisbt/view.php?id=1163

This is fixed in the latest git version.

user838

2014-04-14 09:47

  ~0003010

Hi Martin,

this is great, thanks for fixing it. The bug report link you sent is exactly the same case as mine. I'm currently running the case again to verify that it works.

Gennaro

user838

2014-04-14 15:07

  ~0003011

Dear OF,

Sorry but it hasn't been fixed yet on OF 2.3.x. The fvOptions still doesn't have any effect on the result (also with ridiculously high values) on OF 2.3.x.

Please note that with OF 2.2.2 it used to work.

Thanks

Gennaro

user838

2014-04-17 10:22

  ~0003015

Can please OpenFOAM get back to me on this bug? Thanks

user838

2014-04-24 12:45

  ~0003024

A small update: in order to make the heat source work waiting for the fix, I did a very simple thing which was adding a hard coded heat source:

    for (int nonOrth=0; nonOrth<=nNonOrthCorr; nonOrth++)
    {
        dimensionedScalar myHeatSource
        (
            "myHeatSource", dimensionSet(1, -1, -3, 0, 0), 1760000
        );
        
        fvScalarMatrix hEqn
        (
            thermo.isotropic()
            ? -fvm::laplacian(betav*thermo.alpha(), h, "laplacian(alpha,h)")
            : -fvm::laplacian(betav*tAnialpha(), h, "laplacian(alpha,h)")
          ==
            fvOptions(rho, h)
            + myHeatSource
        );

        hEqn.relax();

        fvOptions.constrain(hEqn);

        hEqn.solve();

        fvOptions.correct(h);
    }

And the outcome is still the same! No effect of the heat source! A logical conclusion is that the bug is elsewhere than fvOptions itself?

But I have no idea where.

As this is a major bug, thanks for fixing it and allowing us to perform simulations.

Thanks and best regards

Gennaro

user21

2014-04-24 12:53

  ~0003025

You need to pull the latest 2.3.x from our repository. The hEqn now reads as :

       fvScalarMatrix hEqn
        (
            (
                thermo.isotropic()
                ? -fvm::laplacian(betav*thermo.alpha(), h, "laplacian(alpha,h)")
                : -fvm::laplacian(betav*tAnialpha(), h, "laplacian(alpha,h)")
            )
          ==
            fvOptions(rho, h)
        );

user838

2014-04-24 15:18

  ~0003027

Last edited: 2014-04-25 08:55

 Hi Sergio, thanks for your feedback. There are now some interesting news following your reply. I pulled the latest 2.3.x from the repository (I was indeed using, by mistake, my compiled chtMultiregion with (FOAM_USER_APPBIN) which was not obviously updated) and tried two things:

1- I ran the bug-fixed version with fvOptions – heat source value 17600.
2- I ran the bug-fixed version with my hard-coded heat source above - heat source value 17600.

The incredible outcome is that now my hard coded heat source works (neither of them worked before the bugfix), but FVOPTIONS KEEPS NOT WORKING, which makes me believe there must be another bug, this time in fvOptions itself.

My fvOptions file is:

FoamFile
{
    version 2.0;
    format ascii;
    class dictionary;
    location "system";
    object fvOptions;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

heatSource
{
    type scalarSemiImplicitSource;
    active on;
    timeStart 0.;
    duration 1e6;
    selectionMode cellSet;
    cellSet heatSource;

    scalarSemiImplicitSourceCoeffs
    {
    // volumeMode absolute; // Values are given as <quantity>
        volumeMode specific; // Values are given as <quantity>/m3

        injectionRateSuSp // Semi-implicit source term S(x) = S_u + S_p x
        {
            h (17600 0);
        }
    }
}

Please try the same check yourself (it takes a few minutes as you can see) to verify it.

Thanks for the support

Gennaro

wyldckat

2014-04-25 21:46

updater   ~0003031

Last edited: 2014-04-25 22:10

 Greetings to all!

Disclaimer: I'm just a fellow bug reporter. I was intrigued about this and decided to give it a try myself.

The conclusion was that this is working properly in OpenFOAM 2.3.x. But it took me more than just a couple of minutes to set up a test case.

@Gennaro: If you wanted feedback faster, you could have at least provided a complete test case, not just a couple of log files :(
Because using my own test case, the injected heat source worked just fine, as proved in the attached test case "planeWall2D_withFvOptions.tar.gz". There is only one "fvOptions" file in this test case, set-up similarly to your example, so it's hard to miss it. When the "fvOptions" file is present, the "wall" region is heated up at least more 10 degrees that without it (after 1000 iterations).

Best regards,
Bruno


edit: Forgot to emphasize that the solver being discussed on this bug report is "chtMultiRegionSimpleFoam" and _not_ "chtMultiRegionFoam". But "chtMultiRegionFoam" should work just as well.

wyldckat

2014-04-25 21:47

updater  

planeWall2D_withFvOptions.tar.gz (5,845 bytes)

user838

2014-04-28 10:24

  ~0003034

Thanks Bruno,

your interest and help is very appreciated.

and in fact your case is almost the same as mine (well done!) and fvOptions doesn't work to you either. In order to verify it please add the following line to the code (on line 23, inside the curly brackets, in solveSolid.H and then compile:

        Info << "fvOptions: " << fvOptions(rho, h) << endl;

and verify that it returns fvOptions: false true false 2000{0}, which means value 0 in all 2000 cells.

If you don't apply temperature gradients in your case (temperature uniform everywhere) expecting temperature gradients generating from the heat source, then you can verify that there's no heat source.

Best Regards

Gennaro

wyldckat

2014-05-01 13:47

updater   ~0003036

Hi Gennaro,

I first assumed the worse and went to investigate the source code.
But the problem seems to be due to the way you're diagnosing this, because the correct line is this:

  Info << "fvOptions: " << fvOptions(rho, h)() << endl;
  
The difference is the extra parenthesis "()". This is needed because "fvOptions(rho, h)" returns an "fvScalarMatrix" wrapped inside a "tmp<>", which means that you'll need to unwrap it before outputting its value. Unwrapping it is done automatically within the equation system, which is why it's not necessary in the defined equation.

If you use "()", you should see something like this:

  fvOptions: false true false 2000{0}
  [1 2 -3 0 0 0 0]

  2000
  (
  -0.176
  -0.176
  ...
  -0.176
  )


  5
  (
  20{0}
  20{0}
  0()
  100{0}
  100{0}
  )
  ...


Best regards,
Bruno

user838

2014-05-01 21:40

  ~0003037

Hi Bruno,

This is great, the problem is fixed and fvOptions now works. So here's what happened:

-Before the bug fix, FvOptions didn't work at all.
-After the bug fix, fvOptions kept not working in my case because of a non-aligned checkMesh fail. Don't ask me how the two things are related, but this is what I experienced and what it can be reproduced at anytime should this be of interest. My simulation is 2D and in order to eliminate the checkMesh fail I ran flattenMesh before splitting the regions.
-Upon verifying fvOptions with the code line above, it would return nothing due to the missing () brackets!

Yes, it's ridiculous.

Thanks Bruno for the valuable help, it was very appreciated.

Best regards

Gennaro

Issue History

Date Modified Username Field Change
2014-04-10 16:31 user838 New Issue
2014-04-10 16:31 user838 File Added: baffleTestCasefvOptions.zip
2014-04-14 08:20 user612 Note Added: 0003009
2014-04-14 09:47 user838 Note Added: 0003010
2014-04-14 15:07 user838 Note Added: 0003011
2014-04-15 16:02 user838 Tag Attached: Heat transfer
2014-04-15 16:02 user838 Tag Attached: chtMultiregionFoam
2014-04-15 16:02 user838 Tag Attached: fvOptions
2014-04-17 10:22 user838 Note Added: 0003015
2014-04-24 12:45 user838 Note Added: 0003024
2014-04-24 12:53 user21 Note Added: 0003025
2014-04-24 12:54 user21 Assigned To => user21
2014-04-24 12:54 user21 Status new => assigned
2014-04-24 12:54 user21 Status assigned => feedback
2014-04-24 15:18 user838 Note Added: 0003027
2014-04-24 15:18 user838 Status feedback => assigned
2014-04-24 16:25 user838 Note Edited: 0003027
2014-04-24 16:25 user838 Note Edited: 0003027
2014-04-25 08:54 user838 Note Edited: 0003027
2014-04-25 08:55 user838 Note Edited: 0003027
2014-04-25 21:46 wyldckat Note Added: 0003031
2014-04-25 21:47 wyldckat File Added: planeWall2D_withFvOptions.tar.gz
2014-04-25 22:10 wyldckat Note Edited: 0003031
2014-04-28 10:24 user838 Note Added: 0003034
2014-05-01 13:47 wyldckat Note Added: 0003036
2014-05-01 21:40 user838 Note Added: 0003037
2014-05-02 10:26 henry Status assigned => closed
2014-05-02 10:26 henry Resolution open => no change required