|
[Sponsors] |
October 31, 2017, 03:42 |
Map fields to a parallel target in OF 2.4.0
|
#1 |
Member
Dominic
Join Date: Jan 2017
Posts: 41
Rep Power: 9 |
Dear Foamers,
I really need helps. I want to map fields from a coarse, huge domain to a smaller, finer domain. The coarse domain is created using blockMesh, and the internal fields is listed as a non-uniform list in the "0" directory.I have visualize the fields in the coarse domain and they have no problems. Then, I created a smaller and finer domain using snappyHexMesh. The geometry is quite complicated, and snappyHexMesh is executed using 8 processors. I am sure that the smaller domain is inside the lager one. Now, I want to initiate the fields in the smaller domain using the fields of the larger domain. So I go into one of the processor files and type the command: Code:
mapFields "the root directory of the case of the larger domain" Code:
--> FOAM FATAL ERROR: Plane normal defined with zero length Bad points:(835993.7481 816206.248 3) (835993.7481 816206.248 4.562488583) (835993.7481 816206.248 6.124976401) From function void plane::calcPntAndVec ( const point&, const point&, const point& ) in file meshes/primitiveShapes/plane/plane.C at line 116. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 Foam::error::abort() at ??:? #2 Foam::plane::calcPntAndVec(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&) at ??:? #3 Foam::tetOverlapVolume::tetTetOverlapVol(Foam::tetPoints const&, Foam::tetPoints const&) const at ??:? #4 Foam::tetOverlapVolume::cellCellOverlapVolumeMinDecomp(Foam::primitiveMesh const&, int, Foam::primitiveMesh const&, int, Foam::treeBoundBox const&) const at ??:? #5 Foam::meshToMeshMethod::interVol(int, int) const at ??:? #6 Foam::cellVolumeWeightMethod::calculateAddressing(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, int, int, Foam::List<int> const&, Foam::List<bool>&, int&) at ??:? #7 Foam::cellVolumeWeightMethod::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&) at ??:? #8 Foam::meshToMesh::calcAddressing(Foam::word const&, Foam::polyMesh const&, Foam::polyMesh const&) at ??:? #9 Foam::meshToMesh::calculate(Foam::word const&) at ??:? #10 Foam::meshToMesh::constructFromCuttingPatches(Foam::word const&, Foam::word const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&) at ??:? #11 Foam::meshToMesh::meshToMesh(Foam::polyMesh const&, Foam::polyMesh const&, Foam::meshToMesh::interpolationMethod const&, Foam::HashTable<Foam::word, Foam::word, Foam::string::hash> const&, Foam::List<Foam::word> const&) at ??:? #12 ? at ??:? #13 ? at ??:? #14 __libc_start_main in "/lib64/libc.so.6" #15 ? at ??:? Aborted Many Thanks! Any comments are appreciated. Dominic |
|
October 31, 2017, 10:28 |
|
#2 |
Member
Anders Utnes
Join Date: May 2017
Location: Norway
Posts: 34
Rep Power: 9 |
I've never seen a plane normal with zero lenght before, but if you appreciate ANY comments than I might aswell try to help you semi-socratically.
Have you tried removing the mapped BC and replacing them with simpler ones that you know works? It will give you the wrong result, but then you will know if the error lays somewhere in your mesh or in your BC. It looks like its refering to a very spesific plane. Snappyhex has a tendency to make almost, but not QUITE perfect planes. usually the corners are a bit approximated. Is it possible you are using a BC that is designed for a perfectly plane surface on a surface that isn't? |
|
November 2, 2017, 04:52 |
|
#3 |
Member
Dominic
Join Date: Jan 2017
Posts: 41
Rep Power: 9 |
Thank you for your help.
I have tried setting all boundary conditions to be "zeroGradient" but this doesn't solve the problem. I found something interesting: After running "decomposePar" and before running "snappyHexMesh", I tried to go into the processor file and run "mapFields". It works well. I also visualize the result and everything is good. However, if I add my geometry into my domain and run "snappyHexMesh" before running "mapFields", the error message comes out again. It seems that mapFields cannot handle complex geometry. Do you have experience on mapping fields from a block mesh to a mesh created by snappyHexMesh? Thanks again. |
|
November 2, 2017, 19:32 |
|
#4 |
Member
Anders Utnes
Join Date: May 2017
Location: Norway
Posts: 34
Rep Power: 9 |
I dont.
I had a geometry earlier however where teh approximation from snappyhexmesh was to inexact, and I ended up having to mesh everything using Gmsh. I've found that Gmsh files take a lot of time to make, but are easy to adjust once you get the hang of it. And meshes often need to be adjusted as the project develops. If you have a unidentified problem tied to your mesh, redoing it in gmsh may be a workaround. If nothing else, it removes the need for using snappyhexmesh. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AMI speed performance | danny123 | OpenFOAM | 21 | October 24, 2020 05:13 |
[swak4Foam] swak4Foam in OpenFoam 2.4.0 | avigrod | OpenFOAM Community Contributions | 8 | May 30, 2016 14:56 |
Compressor Simulation using rhoPimpleDyMFoam | Jetfire | OpenFOAM Running, Solving & CFD | 107 | December 9, 2014 14:38 |
map point Fields in dynamicRefineFvMesh | lukasfischer | OpenFOAM Running, Solving & CFD | 9 | October 26, 2012 11:06 |
PostChannel | maka | OpenFOAM Post-Processing | 5 | July 22, 2009 10:15 |