CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   timeVaryingMappedFixedValue, strange behavier (https://www.cfd-online.com/Forums/openfoam-solving/76477-timevaryingmappedfixedvalue-strange-behavier.html)

panda60 May 26, 2010 11:52

timeVaryingMappedFixedValue, strange behavier
 
Now I am using timeVaryingMappedFixedValue utility,
I do a pre-simulation , and save a lot of time data to disk.
and then I use these data as inlet condition using timeVaryingMappedFixedValue.
but I found the mass flow rate does match with the presimulation.

in presimulation output section, I check the mass flow rate is 1.7475 .
When using timeVaryingMappedFixedValue in the second simulation, I check the inlet boundary flow rate is 1.28. That means timeVaryingMappedFixedValue doesn't read data correctly from the files .

I put points file and a lot of time series data which coreponds to these points in constant/boundaryData/inlet directory.

I don't know if these points and data arrangement should satisfy some requirement.
Can somebody tell me how to arrange these data and point, then timeVaryingMappedFixedValue can read data correctly ?

In its tutorial of simpleFoam/pitzDailyExptInlet , I check the range of z is from -0.0005 to 0.0005 . But why the points file has large z coordinate 0.173 , that meats these points are not in the range of inlet patch .

Could anybody give me some explanation ? Thanks.

panda60 May 26, 2010 12:37

my input data has a lot of points in the boundary edge of inflow patch , if this can cause the problem ?

panda60 May 26, 2010 23:04

It is indeed strange behavior.
I change the first point coordinate from (-0.4 0 0 ) to (-0.4 0 1.01), put this point out of my inflow patch , now the result is right .
When reading data for 100 time steps , I check the contours near inflow position, the result is right.

but once I change the first point coordinate back to the real one, the reading result is not right, why this happens ?

If somebody have used this utility, can give me some suggestions ? Because I have a little worry about this utility.

sega May 27, 2010 07:32

I have used the tool and have not found anything wrong with it.
I even considered it "straight forward"...
There were not that many obstacled to overcome like with other tools.

You should really re-check if the velocity data is corresponding to your points.

How did you get the data from your pre-simulation into the constant/boundaryData/inlet directory?
Did you use the sample tool?

panda60 May 28, 2010 05:07

Quote:

Originally Posted by sega (Post 260499)
I have used the tool and have not found anything wrong with it.
I even considered it "straight forward"...
There were not that many obstacled to overcome like with other tools.

You should really re-check if the velocity data is corresponding to your points.

How did you get the data from your pre-simulation into the constant/boundaryData/inlet directory?
Did you use the sample tool?

Yes ,sega,
I use sample tool. I have checked that my sampled data is indeed corresponding to export points. For example, I saved the simulation data in 16.5 seconds, and then I checked a lot of velocity value corresponding to these points using paraview, the value is exactly the same with exported value using sampling tool.
But it is indeed strange. If I changed the first point z coordinate, the utility can read data correctly. If I changed back to the real point, the readed data is not right.
And I am not sure about its example, I checked the z coordinate is from -0.0005 to 0.0005.
But in its points file, the max z coordinate is 0.173.

elones April 2, 2014 02:23

Hi, have you found the reason why z coordinate is from -0.0005 to 0.0005, but in its points file, the max z coordinate is 0.173?

mhayek April 4, 2014 14:44

Hi all,

I realize this is an old thread, but I'm new to openfoam and looking to use the timeVaryingMappedFixedValue BC to map results from my pre-simulation to my new simulation.

The pre-simulation is a turbulent square-duct LES (pisoFoam) run for a long time with time-steps that match the deltaT of the new simulation. I want to map on the outlet of the pre-simulation U at each timestep to the inlet of the new simulation (pre-sim outlet U field time 0 = sim inlet U field time 0, pre-sim outlet U field time 0.01 = sim inlet U field time 0.01, ...)

I notice that the timeVaryingMappedFixedValue BC requires point values. What is the best way to sample the flow-field to get the point data at a plane? Is it in the function area in controlDict? Will the corresponding points file be generated?

Thanks,
Mike

mhayek April 10, 2014 09:25

Nevermind, I think I found a way that works well. What I did is use surfaceSampling in the controlDict to sample the "outlet" patch of the pre-simulation with the surfaceFormat as foamFile. This saves the U files into directory: case/postProcessing/surfaceSampling/"T"/"outlet"/ where "T" is the timepoint and "outlet" is the patch sampled. In here is the points file and the U field is under the folder vectorField. The points file is the same in all timepoint folders.

I then copied the points file and U files into the appropriate input directory for the new simulations. Unfortunately the files are missing proper headers and the destination directory structure is completely different. I wrote a script (where caseA is the pre-sim, caseB is the new sim) to loop through every caseA timepoint file, copy U file, paste into new directory then add header:

Script looping thru T, copy U file from:
caseA/postProcessing/surfaceSampling/T/outlet/vectorField/
into
caseB/constant/boundaryData/inlet/T
then add header

Manually copy points file from:
caseA/postProcessing/surfaceSampling/T/outlet/
into
caseB/constant/boundaryData/inlet/
and add header

My U boundary condition is now:
inlet
{
type timeVaryingMappedFixedValue;
offset (0 0 0);
setAverage off;
}

I used the pitzDailyExptInlet tutorial to get the headers and input directory format. My scripts to copy and add headers were written in bash, but bash can't use floating point variables (which is how my OpenFOAM output timepoint folders are named) in while or for loop conditionals (as far as I know). So I created a separate C executable that creates a list of the folder names that match the timepoint folder names that need to be copied. This text file is read in as a character list in the for loop conditional (for i in $(< outputfoldernames.txt) ...) and this worked great. Very helpful to automate in my case, since I have ~40,000 timepoint files to copy over and adjust for a second LES simulation.

Z.Q. Niu May 21, 2014 08:16

Dear mhayek,
I have tried your method, but there are too many tiem steps in my case, I am a newer of Linux, Ican't write a bash to copy and add headers to U file, would you mind share your bash and separate C executable file?

Best Regard !
Z.Q. Niu

mhayek May 29, 2014 08:51

1 Attachment(s)
Hi Z.Q.

I myself am relatively new to Linux, C/C++, and OpenFOAM, but this is what I put together for myself. I'm sure there are better ways to do this, but here are the files I used to transfer the outlet U field into the proper input format for the next simulation:

In Zip File:
-READ-ME.txt = Summary containing step-by-step detail instructions (hopefully clear - I made this originally for myself so I remember what I did should I have to repeat the process down the road). you WILL need this to put the following files in the right directories.
-create_folder_names = C executable file
-create_folder_names.c = source code for above file, for reference
-DirReconstruct.sh = bash script file to move outlet files from source directory into proper folder format in the target (input) directory (NOTE: this will need editing to set the correct directory path in multiple places)
-UheaderAdd.sh = bash script file to add header to U files (NOTE: this will need editing to set the correct directory path in multiple places)
-Uheader.txt = header format for U field files, used to add to files

I didn't intend for these to be used by others. It was written for myself to do once or twice, so I apologize for the crudeness or if it's not clear.

I'm redoing this for 250,000 timesteps now and still works well but it does take a while.

Hope that helps
Mike

songwukong April 18, 2016 22:15

Dear mhayek,
I greatly appreciate your masterpiece which helps me badly. Thank you for sharing it!


All times are GMT -4. The time now is 19:46.