|
[Sponsors] |
February 27, 2015, 11:57 |
setField : bug (dam example)
|
#1 |
New Member
Franck HOUSSEN
Join Date: Feb 2015
Posts: 7
Rep Power: 11 |
On the dam example (http://www.openfoam.org/docs/user/damBreak.php), I run :
I guess this is a bug FGH |
|
February 28, 2015, 16:25 |
|
#2 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Quick answer: We are not associated to the NSA, therefore we're not able to see what you're doing in your computer
Anyway, try following these instructions: http://openfoamwiki.net/index.php/Ho...iphase_results |
|
December 13, 2016, 04:52 |
|
#3 |
New Member
Ray
Join Date: Oct 2010
Posts: 1
Rep Power: 0 |
I couldn't see the alpha.water values either in the setup even though I had the cell array value checked for alpha.water. After I solved the simulation with interFoam I did get the results shown in the rest of the tutorial. I think it might be a bug, I am using OpenFOAM 3.0.1
|
|
November 18, 2018, 13:20 |
|
#4 |
New Member
Magnus Hoffmann
Join Date: Sep 2018
Posts: 4
Rep Power: 7 |
Digging this up from two years ago, now using OpenFOAM 6.
It's been bugging me for a while and what works for me is: After executing setFields, there's two alpha.water files: alpha.water (the correct one, verify it by editing it, there should be a long list of 1&0s), if so setField worked correctly alpha.water-orig (or similar) this is the original alpha.water setup file (there should be boundary conditions for your patches). i used to rename them (or setFields does that, i don't remember) but turns out that's not enough, as the header stil says alpha.water Code:
FoamFile { version 2.0; format ascii; class volScalarField; location "0"; object alpha.water; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // I'm curious if it's only a Paraview thing and solvers read in the correct file. |
|
December 22, 2018, 11:24 |
|
#5 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Quick question @CFDMagnus: I'm a bit confused by your description, because I haven't managed to figure out what was the problem exactly...
Any chance you can describe the steps you take that lead to the problem?
__________________
|
|
December 22, 2018, 12:07 |
|
#6 |
New Member
Magnus Hoffmann
Join Date: Sep 2018
Posts: 4
Rep Power: 7 |
The problem is for 2 or more phase problems that the setFields seems to have no effect. Paraview won't show the which internal cells are water/air. It will only show the initial conditions, let's say inlet is displayed with water but walls, atmosphere etc. only air.
For a two phase problem i usually want the domain to be partly filled with water at t=0. I will execute setfields, which overrides alpha.water. The tutorials (and many online tut videos(shout out to Jozsef Nagy) suggest to keep the original alpha.water file under a different name before executing setFields. Every once in a while, paraview will display the initial alpha.water, instead of the desired, after setfields was excecuted. I don't think that is an OpenFOAM problem but related to Paraview. I GUESS that is because paraview checks the headings of the files, which still contains the title alpha.water and gets confused, which one to display. It's not much of an issue but really annoying. Simply moving the originial alpha.water to a different location solves the problem. Hope this was more clear this time |
|
December 22, 2018, 17:23 |
|
#7 |
Retired Super Moderator
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,975
Blog Entries: 45
Rep Power: 128 |
Quick answer: Mmm... ooooh! I didn't know this would happen...
So if I understood you correctly - and I'm using OpenFOAM 6 here too - the problem is because the "alpha.water.orig" field is not shown in the list of fields to be rendered, neither with ParaView's internal reader nor OpenFOAM's reader for ParaView... At least regarding OpenFOAM 6, a feature was added in OpenFOAM to support automatic loading of the ".orig" fields if the actual fields don't exist yet. For example, if only "alpha.water" field doesn't exist yet, then it loads the field "alpha.water.orig" automatically as an alternative. This is why setFields is able to do it so without us having to copy the field as in the past. So, yes, you'll have to either copy the file out of the folder or have it in the folder with another name. The "object" entry within the file isn't always read and it's there mostly for the user to know the last name it was written as... As for the internal reader in ParaView, I'm not sure why exactly it ignores both the "object" entry and the file name itself... at least in ParaView 5.4... |
|
June 16, 2022, 08:05 |
Thank you
|
#8 | |
New Member
Join Date: May 2022
Posts: 2
Rep Power: 0 |
Quote:
From now on I'll stick to having 0.orig and just copying the whole directory |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
mapFields major bug | alchem | OpenFOAM Bugs | 14 | September 15, 2023 12:48 |
Bug in Workbench CFX | Pierre1 | CFX | 6 | August 2, 2017 00:18 |
Thermal and stress modelling of a dam | quimperval | OpenFOAM Running, Solving & CFD | 0 | August 22, 2014 11:08 |
Dam break simulation water level decreases over time | aarratia | FLUENT | 1 | May 9, 2014 10:25 |
3D dam break modeling(earthen dam) | yasharif | FLUENT | 0 | December 11, 2011 01:25 |