View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000580OpenFOAMBugpublic2012-07-11 10:502012-08-02 10:29
Reporteruser469Assigned Touser2 
PrioritynormalSeverityminorReproducibilityrandom
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version10.04
Summary0000580: problem in evaluation of face normal in ParticleErosion.C
DescriptionI think there is a problem with the evaluation of face normal in particleErosion.C with command:

 vector nw = p.currentTetIndices().faceTri(mesh).normal();

When I compare the value of nw to the one provided in standardWallInteraction.C with command:

this->patchData(p, pp, trackFraction, tetIs, nw, Up);

both are different. it looks like that the later one is indeed the face normal, the first one is the tangent.

More, most of the times the evaluation of nw in particleErosion.C is total nonsense, means the normal is aligned with y axis when it should be in the xz plane
Additional InformationI have tested this in the case of a 3d cylinder whose axis is aligned with the y axis.

I'm staying at your disposal if more info is required.
TagsNo tags attached.

Activities

user469

2012-07-11 17:12

  ~0001460

I also tested a case of a cube where I can know the normal of the patches:

this->patchData(p, pp, trackFraction, tetIs, nw, Up); in standardWallInteraction.C provide the accurate normal

 vector nw = p.currentTetIndices().faceTri(mesh).normal(); in particleErosion.C gives nonsense values for the normal

My guess is that there is a problem in the .normal() function but that is for beyond my capacities

Thanks ahead for your comment

Sylvain

user2

2012-08-01 14:28

  ~0001530

Thanks for the report

I've just pushed a potential fix under commit a7fc663 - can you test and report back?

user469

2012-08-01 17:28

  ~0001532

Hi Andy,

Thank you very much for helping me with that. I pulled the last git version and I have compiled only the intermediate library.

I understand now that you use only the following command in order to assess the normal

    this->owner().patchData(p, pp, trackFraction, tetIs, nw, Up);

unfortunately when I run my calculation the following error happens


#0 Foam::error::printStack(Foam::Ostream&) in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigSegv::sigHandler(int) in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 Foam::ParticleErosion<Foam::KinematicCloud<Foam::Cloud<Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > > > >::postPatch(Foam::CollidingParcel<Foam::KinematicParcel<Foam::particle> > const&, Foam::polyPatch const&, double, Foam::tetIndices const&) in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/lib/liblagrangianIntermediate.so"
#4
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#5
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#6
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#7
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#8
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#9
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#10
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#11
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#12
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
#13 __libc_start_main in "/lib/libc.so.6"
#14
 in "/home/calcul/OpenFOAM/OpenFOAM-2.1.x/platforms/linux64GccDPOpt/bin/icoUncoupledKinematicParcelFoam"
[1]+ Done gedit constant/kinematicCloudProperties
Erreur de segmentation

I will take a closer look tomorrow. Maybe have I to compile the whole code?

Thanks ahead

Sylvain

user2

2012-08-01 17:32

  ~0001533

Yes - you'll also need to recompile the solver

user469

2012-08-02 10:24

  ~0001535

Dear Andy,

Works great!!! Many thanks for your help, it's very helpful!! I can go further in my development!!

Best regards

Sylvain

user2

2012-08-02 10:29

  ~0001536

Thanks for the feedback

Issue History

Date Modified Username Field Change
2012-07-11 10:50 user469 New Issue
2012-07-11 17:12 user469 Note Added: 0001460
2012-08-01 14:28 user2 Note Added: 0001530
2012-08-01 17:28 user469 Note Added: 0001532
2012-08-01 17:32 user2 Note Added: 0001533
2012-08-02 10:24 user469 Note Added: 0001535
2012-08-02 10:29 user2 Note Added: 0001536
2012-08-02 10:29 user2 Status new => resolved
2012-08-02 10:29 user2 Fixed in Version => 2.1.x
2012-08-02 10:29 user2 Resolution open => fixed
2012-08-02 10:29 user2 Assigned To => user2