error in compilation of floatingSixDofRigidBodyMotion

[pb628]

Hi pere,

First of all i want thank you for this open-access code and your detailed illustration of the code in your thesis, this is very helpful for me, and i believe also helpful for other newcomer in FOWT coupled dynamics and OpenFOAM. Your paper and code is a great contribution to the community.

I met problem when compling the library 'floatingSixDofRigidBodyMotion': as i following for instruction in 'README-Installation', a error comes like: 'make: *** No rule to make target '/home/pb/OpenFOAM/OpenFOAM-v2012/build/linux64Gcc63DPInt32Opt/src/floatingSixDoFRigidBodyMotion/sixDoFRigidBodyMotion/restraints/constantForce/constantForce.C.dep', needed by '/home/pb/OpenFOAM/OpenFOAM-v2012/build/linux64Gcc63DPInt32Opt/src/floatingSixDoFRigidBodyMotion/sixDoFRigidBodyMotion/restraints/constantForce/constantForce.o'. Stop.'

Then i found the file 'constantForce.C' in the error is not exist in the library files you provided, so i delete the command in Make/files (in line 17, '$(restraints)/constantLoad/constantForce.C'). and then compilation succeed.

I want to know is the constantForce.C file doesn't exist at all or something wrong with my compilation process?

Kind regard

[fronterapp]

Hello!

Thank you very much for your appreciation and interest in this work.

constantForce was a restraint type I introduced in the early stages of the project, but was deprecated in front of the more general constantLoad restraint. You should be safe by deleting the corresponding command.

I have updated the make/files, so it should not throw any compilation error now.

Thanks for noticing!

Best, Pere

[pb628]

thanks

Hello!

Thank you very much for your appreciation and interest in this work.

constantForce was a restraint type I introduced in the early stages of the project, but was deprecated in front of the more general constantLoad restraint. You should be safe by deleting the corresponding command.

I have updated the make/files, so it should not throw any compilation error now.

Thanks for noticing!

Best, Pere

Thanks for your reply!

I want to know how accurate this ALM based CFD models would be, so i'm doing a simple comparison of the fully coupled case results from my OpenFAST and your code. This is case is very simple, it is basically modified from your 'Cases-Chapter7-coupled' except two modifications: (1), i changed the inflow wind profile to a uniform shape with wind speed of 9m/s; (2), i imporved the mesh density of the turbine Zone and wake Zone, now the total cell number is 9M.

the simulation runs successfully but aborted at physic time of 1.78s by a error: "Inflow velocity point for turbine.blade2.element16 not found in mesh"

Did you met this kind of error before? pere. i still can't figure out the reason.

I've attached my mpirun log file where we can see the FOAM error. log.zip

[fronterapp]

It's very nice that you are validating the coupled case from Chapter 7 with OpenFAST! Which aero/hydro/mooring models do you plan to use?

Regarding your question, yes I have faced this error before. I mentioned it in a footnote on page 60 of my MSc thesis. The error is likely related to OpenFOAM's findCell() function, probably when the point lays exactly at a cell face. This error is also present in the original turbinesFoam library, for which I opened an issue a while ago.

First, check that the element in question (blade2.element16 at t = 1.78s) is indeed within the bounding box you defined for your turbine. If it is, then these are some of the things that worked for me in the past are:

1. Change your time-step by a tiny fraction.
2. Use a different domain decomposition (try increasing or decreasing the number of processors by one).
3. Slightly change the mesh refinement near the blades

The goal is to avoid having your actuator line in such a position relative to the mesh that triggers the findCell() error. I also invite you to try the recommendations mentioned here.

Any suggestion on this issue will be very welcomed!

Regards, Pere

[pb628]

It's very nice that you are validating the coupled case from Chapter 7 with OpenFAST! Which aero/hydro/mooring models do you plan to use?

Regarding your question, yes I have faced this error before. I mentioned it in a footnote on page 60 of my MSc thesis. The error is likely related to OpenFOAM's findCell() function, probably when the point lays exactly at a cell face. This error is also present in the original turbinesFoam library, for which I opened an issue a while ago.

First, check that the element in question (blade2.element16 at t = 1.78s) is indeed within the bounding box you defined for your turbine. If it is, then these are some of the things that worked for me in the past are:

1. Change your time-step by a tiny fraction.
2. Use a different domain decomposition (try increasing or decreasing the number of processors by one).
3. Slightly change the mesh refinement near the blades

The goal is to avoid having your actuator line in such a position relative to the mesh that triggers the findCell() error. I also invite you to try the recommendations mentioned here.

Any suggestion on this issue will be very welcomed!

Regards, Pere

Oh much appreciation for your reply! finding the reason of the bug is half way done, this is reaaaaaaly helpful.

I've double check that and did revising to the cases as suggested in your reply and link (setting writePrecision to 12), but that error comes again and again. So i wonder this error will inevitably occur (and maybe more than once) if the simulation timespan is long enough. Now i am working on this issue, i will post the solution here when i find it.

BTW, for the present code, i write a loop in the allRun script which might be useful for the User to skip that bug temporarily. Here, the user can set different timeStep in the three controlDict files, for example the timeStep in my controlDict and controlDict2 is 0.01, and that in controlDict1is 0.0101. And once that bug happened the loop will change the timeStep and going on.

best, bin

[pb628]

It's very nice that you are validating the coupled case from Chapter 7 with OpenFAST! Which aero/hydro/mooring models do you plan to use?

Regarding your question, yes I have faced this error before. I mentioned it in a footnote on page 60 of my MSc thesis. The error is likely related to OpenFOAM's findCell() function, probably when the point lays exactly at a cell face. This error is also present in the original turbinesFoam library, for which I opened an issue a while ago.

First, check that the element in question (blade2.element16 at t = 1.78s) is indeed within the bounding box you defined for your turbine. If it is, then these are some of the things that worked for me in the past are:

1. Change your time-step by a tiny fraction.
2. Use a different domain decomposition (try increasing or decreasing the number of processors by one).
3. Slightly change the mesh refinement near the blades

The goal is to avoid having your actuator line in such a position relative to the mesh that triggers the findCell() error. I also invite you to try the recommendations mentioned here.

Any suggestion on this issue will be very welcomed!

Regards, Pere

sorry for missing your question, Actually that's my team's FAST simulation, we uses BEM for aerodynamics, Potential flow theory with Morison equation for hydrodynamics, and lumped mass method for mooring line dynamics.

best, Bin

[byChen47]

Dear @pb628 , I want to know whether you can run the turbines_only,and if you can run it, could you change it and to run another case? This is my case ,when I run the case in turbinesFoam, it's ok，but when I run by libfloatingTurbinesFoam ,which can't run. So I want to ask for you help.

Thanks you very much chen. this is case 9.turbines_2Mesh_61d5.zip

[pb628]

Dear @pb628 , I want to know whether you can run the turbines_only,and if you can run it, could you change it and to run another case? This is my case ,when I run the case in turbinesFoam, it's ok，but when I run by libfloatingTurbinesFoam ,which can't run. So I want to ask for you help.

Thanks you very much chen. this is case 9.turbines_2Mesh_61d5.zip

hi Chen, I did not run the turbine_only case, can you provide your logfile? maybe we can figure it out. Best