[JonL]

Hey everyone,


being rather new to using OpenFOAM I would like to implement an additional light source to my current simulations of a polymere-based additive manufacturing process. The idea is to simulate the heat absorption of named light source and observe temperature increase and melting.

As I am running my simulations on a university cluster I am limited to using the OpenFOAM-v2006 version (or OpenFOAM-7, but this one does not include the icoReactingMultiPhaseInterFoam solver that I would like to use).

During my research on this forum and other sources I have only found 2 ways to realize my goals:

1) The laser convection boundary condition, originally introduced by Tobias Holzmann (https://bitbucket.org/shor-ty/laserconvectionbc).
This one would be the optimal solution for my application, but sadly it does not seem to be compiling properly in v2006 - and I don't currently have the option to switch back to v1812/ v1912.

2) The Laser DTRM function is included in the icoReactingMultiPhaseInterFoam solver, but I have not rly found a proper way to put this one into good use.

Any ideas and recommendations are gladly appreciated!

Greetings,

Jon

[olesen]

Originally Posted by JonL

1) The laser convection boundary condition, originally introduced by Tobias Holzmann (https://bitbucket.org/shor-ty/laserconvectionbc).
This one would be the optimal solution for my application, but sadly it does not seem to be compiling properly in v2006 - and I don't currently have the option to switch back to v1812/ v1912.

It should not take very much to get it compiling with v2006. Most of the compilation errors are likely related to sloppy conversion of dictionary lookups to variables. Eg,

word foo = dict.lookup("foo");  // bad, cannot convert ITstream to word
word foo(dict.lookup("foo");  // good, construct from stream
word foo(dict.get<word>("foo"));  // with check for trailing junk

bool bar = dict.lookup("bar");  //??? 

bool bar = readBool(dict.lookup("bar"));
bool bar = Switch(dict.lookup("bar"));
bool bar = dict.get<bool>("bar");

[JonL]

Originally Posted by olesen

It should not take very much to get it compiling with v2006. Most of the compilation errors are likely related to sloppy conversion of dictionary lookups to variables. Eg,

word foo = dict.lookup("foo");  // bad, cannot convert ITstream to word
word foo(dict.lookup("foo");  // good, construct from stream
word foo(dict.get<word>("foo"));  // with check for trailing junk

bool bar = dict.lookup("bar");  //??? 

bool bar = readBool(dict.lookup("bar"));
bool bar = Switch(dict.lookup("bar"));
bool bar = dict.get<bool>("bar");

Thank you very much for the quick response!

Sadly I am too uneducated with the whole Syntax and everything else included in the OpenFoam libraries to fully be able to understand your otherwise probably very helpful hint.

With what I can recall from memory (currently in Homeoffice, so I can't print the exact error message), most of the compiling errors occured whenever the "XY.append()" was called, stating Syntax errors in those lines.

I do admit this vague information is most likely unhelpful, but thanks for your tip and I'll try to look further into it.

[olesen]

Originally Posted by JonL

Thank you very much for the quick response!

Sadly I am too uneducated with the whole Syntax and everything else included in the OpenFoam libraries to fully be able to understand your otherwise probably very helpful hint.

With what I can recall from memory (currently in Homeoffice, so I can't print the exact error message), most of the compiling errors occured whenever the "XY.append()" was called, stating Syntax errors in those lines.

I do admit this vague information is most likely unhelpful, but thanks for your tip and I'll try to look further into it.

I cloned and quickly chucked it at the compiler. Your memory is correct, the errors with the various appends are the same thing as I mentioned previously.
The openfoam.com version has become much pickier about implicit conversions. This is annoying for cases like this, where you would just like get things compiling. On the other hand, it does not really make much sense (other than laziness) to implicitly construct something like a vector or a point from a stream, which is what the laser BC code is currently doing.