CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

Accessing PtrList of fields from boundary condition

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   March 27, 2020, 05:04
Default Accessing PtrList of fields from boundary condition
  #1
Member
 
Andrea Di Ronco
Join Date: Nov 2016
Location: Milano, Italy
Posts: 57
Rep Power: 9
Diro7 is on a distinguished road
Hello!

I'm trying to implement a boundary condition based on mixed in which I need to access some fields which are updated at runtime, but not read nor written to file.
Looking around in other BCs I've found that the usual syntax reads as:
Code:
const fvPatchScalarField& Dp = patch().lookupPatchField<volScalarField, scalar>(DName_);
where Dp is the retrieved field and DName_ is its name (as usual read from BC dictionary).

The field I want to retrieve is created during solver initialisation as usual, and updated at each solver iteration. It is created as:
Code:
PtrList<volScalarField> D(n);

forAll(D, i)
{
    word iName = name(i + 1);
    D.set
    (
        i,
        new volScalarField
        (
            IOobject
            (
                "D" + iName,
                runTime.timeName(),
                mesh,
                IOobject::NO_READ,
                IOobject::NO_WRITE
            ),
            mesh,
            D_ref[i]
        )
    );
}
The reason is that each component of the list D has to be used in a different equation, and since such equations solve for different variables but are identical in form I also loop during solution over the solved variable fields which are stored in another PtrList themselves.

In the BC, the string DName_ is set to "D1", "D2", ... consistently with the IOobject objects which are created with name "D" + name(i + 1) as the code snippet shows.
Unfortunately, the following error arises:
Code:
[0] [1] 
[1] 
[1] --> FOAM FATAL ERROR: [2] 
[2] 
[2] --> FOAM FATAL ERROR: 
[2] 
    request for volScalarField D1 from objectRegistry region0 failed
    available objects of type volScalarField are

46
(
... other fields that can be retrieved ...
 )
I can't understand why, since the error output lists a lot of fields I create and use in the solver, some of which are created as:
Code:
volScalarField randomField
(
    IOobject
    (
        "randomField",
        runTime.timeName(),
        mesh,
        IOobject::NO_READ,
        IOobject::NO_WRITE
    ),
    mesh,
    randomDummyScalar
 );
which is basically the same stuff with the only difference of not being set as components of a PtrList. Even more strangely, the fields I solve for using the D[i] are created in the same exact way as the D[i], with the only difference being the IO flags set to MUST_READ and AUTO_WRITE, but they are listed in the error output as found in the objectRegistry.

Does anyone know what the reason of this behaviour could be?
Thanks in advance for the help.

Andrea
Diro7 is offline   Reply With Quote

Old   April 8, 2020, 11:54
Default
  #2
New Member
 
Bruno
Join Date: Jul 2018
Posts: 6
Rep Power: 7
Onurb is on a distinguished road
Hello, Andrea.

I am faced with the same problem. However, I am trying to access a field inside a PtrList<volScalarField> to implement a new viscosity model.

Could you tell me if you were successful in solving your problem
Onurb is offline   Reply With Quote

Old   April 8, 2020, 12:17
Default
  #3
Member
 
Andrea Di Ronco
Join Date: Nov 2016
Location: Milano, Italy
Posts: 57
Rep Power: 9
Diro7 is on a distinguished road
Hi Bruno,

I was indeed able to solve my problem. The issue in my case was that I was messing up things while updating the field at each time step. The initialization code I showed was actually fine.

Basically, I was using the set() method also to update PtrList components, but in the update phase I was assigning a new volScalarField without constructing it as a IOobject. So, correctly, right after the first call to the update routine the field wasn't registered to the objectRegistry anymore.

Therefore I solved it by not using set() to update the fields. Now I simply use
Code:
forAll(D, i)
{
    D[i] = "new expression";
}
which doesn't require the creation of a new IOobject.

Hope it helps!

Andrea
Diro7 is offline   Reply With Quote

Old   April 8, 2020, 12:37
Default
  #4
New Member
 
Bruno
Join Date: Jul 2018
Posts: 6
Rep Power: 7
Onurb is on a distinguished road
Hi Andrea,

Many thanks for your reply. Could you say what is D_ref[i] in your initialization?
Onurb is offline   Reply With Quote

Old   April 8, 2020, 12:58
Default
  #5
Member
 
Andrea Di Ronco
Join Date: Nov 2016
Location: Milano, Italy
Posts: 57
Rep Power: 9
Diro7 is on a distinguished road
Hi Bruno,

in my solver the D[i] is a property field which only depends on temperature, and D_ref[i] is the reference value of the field calculated at a reference temperature.

D_ref[i] is therefore a dimensionedScalar, part of the PtrList<dimensionedScalar> D_ref which is created during initialization too from dictionary file.
If you use this same constructor to populate D, D_ref[i] can be any dimensionedScalar with the right physical dimensions.
Diro7 is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Constant mass flow rate boundary condition sahm OpenFOAM 0 June 20, 2018 22:45
Problem accessing data in point boundary condition Jibran OpenFOAM Programming & Development 0 February 28, 2018 12:12
Error - Solar absorber - Solar Thermal Radiation MichaelK CFX 12 September 1, 2016 05:15
Accessing a field value in a boundary condition wildfire230 OpenFOAM Running, Solving & CFD 5 July 22, 2015 17:44
RPM in Wind Turbine Pankaj CFX 9 November 23, 2009 04:05


All times are GMT -4. The time now is 06:44.