[ari003]

Hi, guys I have been trying to do some simulation in OF7 and there I noticed that it has really changed a lot since it s previous version.
So basically I was trying the pitzdaily tutorial and my aim is to get the output velocities of each face/cell and feed it as an input boundary of another pitz daily case setup. I have cut out a surface using surfaces dict and got the velocities but that corresponds to the vertex points. To make it clear lets say I have 30 cells and 62 vertex points so the velocity which are needed to be fed in the new simulation should be 30 in number corresponding to each cell and not 62. So, how can I get the output velocity corresponding to each cell/face in my first pitzdaily case setup? It will of great help if anyone responds to my thread.

[ari003]

Can anyone help out to solve this issue? I have been stuck in this for the past 2 days. Any kind of help will greatly encouraged.

[crubio.abujas]

Hello ari003,

Let me go bit by bit and tell me if I got something wrong. You want to do two separate simulations, pitzdaily1 and pitzdaily2.
1) From pitzdaily1 you want to extract the velocity profile of the outlet.
2) You want to use this in velocity profile as an input for the pitzdaily2.
right?

If that is the case, the point 1 can be addressed with a functionObject like this one:

outletSampled
{
    type            surfaceFieldValue;
    libs            ("libfieldFunctionObjects.so");
    regionType      patch;
    name            outlet;
    operation       none;

    writeFields     true;
    surfaceFormat   foam; 
    fields
    ( 
        U 
    );
}

This will write the results into the postProcess folder into 4 separate files:

• faceCenters - with the coordinte of the face centers
• vectorFields/U - with the velocity on the face centers
• faces - with the reference of the points conforming the face
• points - with the coordinate of all the points conforming the face

with that you shall have enough information to do the point 2, although some processing is required.


Ok, lets go with the point 2. How do you feed this information as a boundary condition? You can check the pitzDailyExptInlet tutorial, which uses the timeVaryingMappedFvPatchField boundary condition. What this does is quite close to what you want, it reads a PatchProfile and uses it as a boundary condition. By default it tries to read the input profile in the folder constant/boundaryData/<patch_name> where it expects to find:

• a file "points" with the coordinate of all the points defining the profile
• a folder for each timestep the profile is defined. This profile must have a field for each profile correspondent with the point files previously defined.

That is really similar to what we get from pitzdaily1, right? You may be tempted to just use the faceCenter and the U profiles, renamed properly and feed into pitzdaily2 but that wont work. That is because geometrically these two patches don't match. They have different sizes and are places in different points in the space, so you have to figure out a way to project the output information into de input geometry for that to work.

You can try doing further manipulation of the data for adequate the timeVaryingMappedFvPatchField, in that case maybe a different surfaceFormat may be better, depending on the platform you're more used to worh with.
Other option may be merging two pitzlyday meshes and do this in a single run, rather making the connection explicit or using some king of interface between these two.

I hope that helps you to going further with the problem!

[ari003]

First of all I want to thank you for such a great effort. Yaa, I ve taken a slice by using surface dict which is giving the value corresponding to points but I want corresponding to cell center. I m using Openfoam 7 and that might be a reason why I m unable to get these functionObject features. Bdw which version you are using and how did you het the dict of functionObject?

[ari003]

I will be eagerly waiting for your reply Sir, as my work is stuck at this point and I need to get it done as soon as possible. I hope you understand.

[crubio.abujas]

hi again ari003,

Originally Posted by ari003

First of all I want to thank you for such a great effort. Yaa, I ve taken a slice by using surface dict which is giving the value corresponding to points but I want corresponding to cell center.

If in the end you want to apply a boundary condition I think the proper thing to follow shall be the face value. Anyway, I think if you're using a zeroGradient condition on the outlet OF is just using the same cell center value to the faceCenter, without any interpolation. That way the gradient between these two point shall be 0.

Anyway, in the functionObject you can set the interpolationScheme to cell. According to the documentation this interpolationScheme considers the cell center value to be applicable to the entire cell, so combined with your surfaceDict you should get the results you want. Concerning the coordinates of the centers, if on your surfaceDict you've already sliced the region of interest, the "faceCenter" shall match the center of these cells. If you want to be more precise you can check cellCenters (http://openfoamwiki.net/index.php/Contrib/cellCenters), which I assume creates a vector field with the position of the center, combined with the interpolationScheme=cell that should give you the expected result.

If is just post-processing you can try checking paraview. There you can see the value of the cells/points, selected the interesting ones using graphical tools and exporting into a spreadsheet.

However, I want to highlight that output and inlet geometries are different and for creating a match among them you must do some further processing.

Originally Posted by ari003

I m using Openfoam 7 and that might be a reason why I m unable to get these functionObject features. Bdw which version you are using and how did you het the dict of functionObject?

I'm using OF7 as well. Concerning the funcionObject Dict, I just look around the src folder using the commands find and grep to locate potentially useful functionObjects. The .H file use to have a header with information on how to call these objects. Then I just sequentially fill the functionObject, run and listen to the complains of OF e.g it tells you the field "surfaceType" is missing, you add it with a dummy value, then is tell you "dummy value is not valid. These are the valid values" pick one and repeat. It may not be the most elegant way to do it... but it works. You can also use grep to look on the tutorials for any case wich uses these kind of object.


Hope it helps!

[ari003]

Respected Sir,
Your response was so generous that I am finally able to get the desired output. Thank you. If I need further assistance I ll write it here.
Yours faithfully
Arijit

[ari003]

Originally Posted by crubio.abujas

Hello ari003,

Let me go bit by bit and tell me if I got something wrong. You want to do two separate simulations, pitzdaily1 and pitzdaily2.
1) From pitzdaily1 you want to extract the velocity profile of the outlet.
2) You want to use this in velocity profile as an input for the pitzdaily2.
right?

If that is the case, the point 1 can be addressed with a functionObject like this one:

outletSampled
{
    type            surfaceFieldValue;
    libs            ("libfieldFunctionObjects.so");
    regionType      patch;
    name            outlet;
    operation       none;

    writeFields     true;
    surfaceFormat   foam; 
    fields
    ( 
        U 
    );
}

This will write the results into the postProcess folder into 4 separate files:

• faceCenters - with the coordinte of the face centers
• vectorFields/U - with the velocity on the face centers
• faces - with the reference of the points conforming the face
• points - with the coordinate of all the points conforming the face

with that you shall have enough information to do the point 2, although some processing is required.


Ok, lets go with the point 2. How do you feed this information as a boundary condition? You can check the pitzDailyExptInlet tutorial, which uses the timeVaryingMappedFvPatchField boundary condition. What this does is quite close to what you want, it reads a PatchProfile and uses it as a boundary condition. By default it tries to read the input profile in the folder constant/boundaryData/<patch_name> where it expects to find:

• a file "points" with the coordinate of all the points defining the profile
• a folder for each timestep the profile is defined. This profile must have a field for each profile correspondent with the point files previously defined.

That is really similar to what we get from pitzdaily1, right? You may be tempted to just use the faceCenter and the U profiles, renamed properly and feed into pitzdaily2 but that wont work. That is because geometrically these two patches don't match. They have different sizes and are places in different points in the space, so you have to figure out a way to project the output information into de input geometry for that to work.

You can try doing further manipulation of the data for adequate the timeVaryingMappedFvPatchField, in that case maybe a different surfaceFormat may be better, depending on the platform you're more used to worh with.
Other option may be merging two pitzlyday meshes and do this in a single run, rather making the connection explicit or using some king of interface between these two.

I hope that helps you to going further with the problem!

While I was successful in doing the first part but with the second part I m facing some trouble while running. I ve made the boundaryData folder with my own values as it is done the pitzdailyExpInlet but still the error persist. The error is as follows:-
Reading field U

#0 Foam::error:rintStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam:ointToPointPlanarInterpolation::calcCoordin ateSystem(Foam::Field<Foam::Vector<double> > const&) const at ??:?
#4 Foam:ointToPointPlanarInterpolation:ointToPoin tPlanarInterpolation(Foam::Field<Foam::Vector<doub le> > const&, Foam::Field<Foam::Vector<double> > const&, double, bool) at ??:?
#5 Foam::timeVaryingMappedFvPatchField<Foam::Vector<d ouble> >::checkTable() at ??:?
#6 Foam::timeVaryingMappedFvPatchField<Foam::Vector<d ouble> >::map() at ??:?
#7 Foam::timeVaryingMappedFixedValueFvPatchField<Foam ::Vector<double> >::timeVaryingMappedFixedValueFvPatchField(Foam::f vPatch const&, Foam:imensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#8 Foam::fvPatchField<Foam::Vector<double> >::adddictionaryConstructorToTable<Foam::timeVaryi ngMappedFixedValueFvPatchField<Foam::Vector<double > > >::New(Foam::fvPatch const&, Foam:imensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#9 Foam::fvPatchField<Foam::Vector<double> >::New(Foam::fvPatch const&, Foam:imensionedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#10 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam:imensio nedField<Foam::Vector<double>, Foam::volMesh> const&, Foam::dictionary const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#11 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#12 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::readFields() in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#13 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#14 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
#15 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#16 ? in "/opt/openfoam7/platforms/linux64GccDPInt32Opt/bin/pimpleFoam"
Floating point exception (core dumped)
arijit@arijit-VirtualBox:~/Desktop/pitzDaily$ ^C
arijit@arijit-VirtualBox:~/Desktop/pitzDaily$

Any idea to troubleshoot this will be really appreciable.
Thank you

[crubio.abujas]

Hello again Arijit!

Originally Posted by ari003

While I was successful in doing the first part but with the second part I m facing some trouble while running. I ve made the boundaryData folder with my own values as it is done the pitzdailyExpInlet but still the error persist. The error is as follows:-
Reading field U

I've made some investigation on the case and it seems that timeVaryingMappedFixedValue is trying to do an interpolation on the Z axis, but as the model is 2D the set of points provided only have a single Z value (so zmax and zmin are equal and probably the interpolation blows up dividing by 0).

If you check the pitzdailyExpInlet tutorial and see the definition of boundaryData/inlet/points you can see that there is an duplicated set of points with an offset in z-direction.

/* - boundaryData/inlet/points  - */

70  // Ensure to change the length of the array!
(

// min z 
(-0.0206 0.000125 0)
(-0.0206 0.000375 0)
(-0.0206 0.000625 0)
...

// max z (A duplicate set of coordinates with different Z value)
(-0.0206 0.000125 0.173)
(-0.0206 0.000375 0.173)
(-0.0206 0.000625 0.173)
...

)

Of course you must create a duplicate set on de U field to be interpolated against. Ensure that the vector lengths at the beginning match the number of elements inside!

I've tried the case with this modifications and it worked fine, so lets hope it works well for you as well!

[minzhang]

Hello,

If I want to use the inlet velocity profile to the inlet for the second simulation, how should I approach the second step?

Thanks and best regards,
Min

[minzhang]

Hello,

If I want to feed the inlet velocity profile to inlet (the same patch) for another simulation, how should I approach the second step?

In addition, I tried the code in Step 1 and I am using simpleFoam solver in OpenFOAM 5:

inletSampled
{
    type            surfaceFieldValue;
    libs            ("libfieldFunctionObjects.so");
    regionType      patch;
    name            pbc_top;
    operation       none;

    writeFields     true;
    surfaceFormat   foam; 
    fields
    ( 
        U 
    );

But I found that the results in postProcessing/inletSampled/surface folder does not include the last time step. I am wondering why and what I should do to get the info for the last time step.

Thanks,
Min

Originally Posted by crubio.abujas

Hello ari003,

Let me go bit by bit and tell me if I got something wrong. You want to do two separate simulations, pitzdaily1 and pitzdaily2.
1) From pitzdaily1 you want to extract the velocity profile of the outlet.
2) You want to use this in velocity profile as an input for the pitzdaily2.
right?

If that is the case, the point 1 can be addressed with a functionObject like this one:

outletSampled
{
    type            surfaceFieldValue;
    libs            ("libfieldFunctionObjects.so");
    regionType      patch;
    name            outlet;
    operation       none;

    writeFields     true;
    surfaceFormat   foam; 
    fields
    ( 
        U 
    );
}

This will write the results into the postProcess folder into 4 separate files:

• faceCenters - with the coordinte of the face centers
• vectorFields/U - with the velocity on the face centers
• faces - with the reference of the points conforming the face
• points - with the coordinate of all the points conforming the face

with that you shall have enough information to do the point 2, although some processing is required.


Ok, lets go with the point 2. How do you feed this information as a boundary condition? You can check the pitzDailyExptInlet tutorial, which uses the timeVaryingMappedFvPatchField boundary condition. What this does is quite close to what you want, it reads a PatchProfile and uses it as a boundary condition. By default it tries to read the input profile in the folder constant/boundaryData/<patch_name> where it expects to find:

• a file "points" with the coordinate of all the points defining the profile
• a folder for each timestep the profile is defined. This profile must have a field for each profile correspondent with the point files previously defined.

That is really similar to what we get from pitzdaily1, right? You may be tempted to just use the faceCenter and the U profiles, renamed properly and feed into pitzdaily2 but that wont work. That is because geometrically these two patches don't match. They have different sizes and are places in different points in the space, so you have to figure out a way to project the output information into de input geometry for that to work.

You can try doing further manipulation of the data for adequate the timeVaryingMappedFvPatchField, in that case maybe a different surfaceFormat may be better, depending on the platform you're more used to worh with.
Other option may be merging two pitzlyday meshes and do this in a single run, rather making the connection explicit or using some king of interface between these two.

I hope that helps you to going further with the problem!

[ari003]

Originally Posted by minzhang

Hello,

If I want to feed the inlet velocity profile to inlet (the same patch) for another simulation, how should I approach the second step?

In addition, I tried the code in Step 1 and I am using simpleFoam solver in OpenFOAM 5:

inletSampled
{
    type            surfaceFieldValue;
    libs            ("libfieldFunctionObjects.so");
    regionType      patch;
    name            pbc_top;
    operation       none;

    writeFields     true;
    surfaceFormat   foam; 
    fields
    ( 
        U 
    );

But I found that the results in postProcessing/inletSampled/surface folder does not include the last time step. I am wondering why and what I should do to get the info for the last time step.

Thanks,
Min

I've attached the screenshot. Check that out. The 'point' represents the surface center co-ordinate.

[minzhang]

I am sorry. I could not understand what you are trying to do? Could you explain more?

Originally Posted by ari003

I've attached the screenshot. Check that out. The 'point' represents the surface center co-ordinate.

[ari003]

Originally Posted by minzhang

I am sorry. I could not understand what you are trying to do? Could you explain more?

Sorry for the late reply. As you asked about step 1, this will create a folder containing the values at all the cells lying on the plane (1 1 1) at every time-step. For your case the x-coordinate will be 0.
For step 2 you can follow timeVarying Mapped Field.

[Behradskn]

Originally Posted by crubio.abujas

Hello ari003,

Let me go bit by bit and tell me if I got something wrong. You want to do two separate simulations, pitzdaily1 and pitzdaily2.
1) From pitzdaily1 you want to extract the velocity profile of the outlet.
2) You want to use this in velocity profile as an input for the pitzdaily2.
right?

If that is the case, the point 1 can be addressed with a functionObject like this one:

outletSampled
{
    type            surfaceFieldValue;
    libs            ("libfieldFunctionObjects.so");
    regionType      patch;
    name            outlet;
    operation       none;

    writeFields     true;
    surfaceFormat   foam; 
    fields
    ( 
        U 
    );
}

This will write the results into the postProcess folder into 4 separate files:

• faceCenters - with the coordinte of the face centers
• vectorFields/U - with the velocity on the face centers
• faces - with the reference of the points conforming the face
• points - with the coordinate of all the points conforming the face

with that you shall have enough information to do the point 2, although some processing is required.


Ok, lets go with the point 2. How do you feed this information as a boundary condition? You can check the pitzDailyExptInlet tutorial, which uses the timeVaryingMappedFvPatchField boundary condition. What this does is quite close to what you want, it reads a PatchProfile and uses it as a boundary condition. By default it tries to read the input profile in the folder constant/boundaryData/<patch_name> where it expects to find:

• a file "points" with the coordinate of all the points defining the profile
• a folder for each timestep the profile is defined. This profile must have a field for each profile correspondent with the point files previously defined.

That is really similar to what we get from pitzdaily1, right? You may be tempted to just use the faceCenter and the U profiles, renamed properly and feed into pitzdaily2 but that wont work. That is because geometrically these two patches don't match. They have different sizes and are places in different points in the space, so you have to figure out a way to project the output information into de input geometry for that to work.

You can try doing further manipulation of the data for adequate the timeVaryingMappedFvPatchField, in that case maybe a different surfaceFormat may be better, depending on the platform you're more used to worh with.
Other option may be merging two pitzlyday meshes and do this in a single run, rather making the connection explicit or using some king of interface between these two.

I hope that helps you to going further with the problem!

Hi Carlos,

I just found this reply from you which I think can help me with the issue I'm dealing with it. I want to embed a simple transport equation inside another domain which is governed by twoPhaseEulerFoam solver. So far I have made some cyclic boundary conditions around the region which I want to solve this transport equation to get access to the surfaceFields of that region and also I have access to the cell ids in this small region inside my domain. For implementing of this transport equation inside the domain I need to use the surfaceFields as a boundary condition (let's assume I want to have a BC for U at the surfaces of the embedded small region), Do you think that timeVaryingMappedFVPatchField will be helpful to somehow write the patchfields in every time step from twoPhaseEulerFoam and use them as a BC for my transport equation?
or as you mentioned in your message "Other option may be merging two pitzlyday meshes and do this in a single run, rather making the connection explicit or using some king of interface between these two." should I try these ideas? Can you explain these ideas a bit more?

Thank you so much!
Behrad

[crubio.abujas]

Hi Behradskn,

I understand that what you’re willing to do is to perform two simulations: one for the twoPhaseEulerFoam model on the general domain (case A) and another on a subdomain where you only solve a transport equation (case B). Is that right?

Yes, I would say that the approach of extracting the surface profile of your subdomain from case A to apply it as a boundary condition to the case B should work properly. I guess you can use topoDict to determine a faceSet corresponding to the boundary of the case B subdomain and export while computing the case A. Depending on the geometry of the subdomain and the mesing the matching of the faceSet and the real domain may change. I think it would interpolate the minor differences, but it is important to check it to be as good as possible.

Concerning the single-simulation approach, in this case you should include a transport equation in a custom solver (doing only some minor changes on the twoPhaseEulerFoam solver). There are some tutorials on the internet on how to implement a transport equation on a custom solver, so you can take a look. In that case you will solve the transport equation on the entire domain (not only on the submodel), which should cause a minor increment in the computation time. The only tricky point is if you really need to do the injection of your transport scalar inside the domain, where you should check some kind of custom source term.

Alternatively, to this single-simulation approach, you can achieve the same result without a custom solver by doing two simulations on the same domain. One with the twoPhaseEulerFoam (case C1) and another one with a transportFoam (case C2) using the results of the case C1. In this approach you would decouple the scalar transport from the fluid movement, which may have some advantages if you want to play around with the transport model, as the case C2 would be much less computationally expensive.