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

Map fields to a parallel target in OF 2.4.0

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   October 31, 2017, 02:42
Default Map fields to a parallel target in OF 2.4.0
  #1
Member
 
Dominic
Join Date: Jan 2017
Posts: 41
Rep Power: 9
DominicTNC is on a distinguished road
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"
However, I always get the following error message:
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
I am using OpenFOAM 2.4.0. Is there any idea what's wrong?

Many Thanks! Any comments are appreciated.

Dominic
DominicTNC is offline   Reply With Quote

Old   October 31, 2017, 09:28
Default
  #2
Member
 
Anders Utnes
Join Date: May 2017
Location: Norway
Posts: 34
Rep Power: 8
Alasir is on a distinguished road
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?
Alasir is offline   Reply With Quote

Old   November 2, 2017, 03:52
Default
  #3
Member
 
Dominic
Join Date: Jan 2017
Posts: 41
Rep Power: 9
DominicTNC is on a distinguished road
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.
DominicTNC is offline   Reply With Quote

Old   November 2, 2017, 18:32
Default
  #4
Member
 
Anders Utnes
Join Date: May 2017
Location: Norway
Posts: 34
Rep Power: 8
Alasir is on a distinguished road
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.
Alasir 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
AMI speed performance danny123 OpenFOAM 21 October 24, 2020 04:13
[swak4Foam] swak4Foam in OpenFoam 2.4.0 avigrod OpenFOAM Community Contributions 8 May 30, 2016 13:56
Compressor Simulation using rhoPimpleDyMFoam Jetfire OpenFOAM Running, Solving & CFD 107 December 9, 2014 13:38
map point Fields in dynamicRefineFvMesh lukasfischer OpenFOAM Running, Solving & CFD 9 October 26, 2012 10:06
PostChannel maka OpenFOAM Post-Processing 5 July 22, 2009 09:15


All times are GMT -4. The time now is 21:08.