[wyldckat]

Hi Srivaths,

OK, once in possession of source code, it made it a lot easier to figure out the problem. Attached is a working build and loading library, but I have not tested the boundary conditions themselves

So the problem was rather simple:

1. In "newDirectionMixedFvPatchVectorField.H" you were indicating that definitions for "autoMap" and "rmap" would be given at a later time.
2. But in "newDirectionMixedFvPatchVectorField.C", you had the code for them commented out.
3. Result: the library wouldn't load because the aforementioned methods were nowhere to be found and they are needed, given the inherited class structure.

Now, two solutions can be done:

1. You can comment out the respective code in the header file as well (which I did), since the methods in question were virtual and it's not obligatory in this case to declare them as well in this derived class.
2. Or you could uncomment the respective code from the ".C" file.

For more information about C++, I advise you to study this tutorial: http://www.cplusplus.com/doc/tutorial/

Best regards,
Bruno

[Sherlock_1812]

Hi Bruno,

Thank you so much for clearing that issue!

To be frank I didn't quite understand what autoMap and rmap meant as I was simply doing changes to another derived BC. I have an idea now. I will have a look at the link you have given me and avoid mistakes like them in the future. (hopefully a few others as well)

Wishing you in advance for a Happy 2014! Its almost 00:00 AM here!

[babakflame]

Greetings Bruno

Many thanks for your valuable information in this thread. I found the way in "tutorials/incompressible/simpleFoam/pitzDailyExptInlet"much simpler than groovy.

I want to implement this approach for my case. I have a wedge-typed grid that the inlet velocity profile is known from another simulation.

In the tutorial that you introduced, the velocities are identified for points along the min and maximum Z .

But what about a wedge-typed grid? I have attached a pic of my grid.

In Z direction only one cell occurs. If I define my velocities in Z=0 line, I have the values on cell centers (I think) or do I need to define the velocities on the points located on the upper and lower sides of the triangle?

Does it differ? Would you PLZ hint me?

Best,
Bobi

[babakflame]

Greetings Bruno

About the method described in: "tutorials/incompressible/simpleFoam/pitzDailyExptInlet"

I checked that whether I need to determine the velocity profile on the upper and lower sides of the inlet triangle or can I adjust it on the middle of the triangle i.e the location of Z=0

I found out that we can just pre-determine the values of the velocity only on the sides of the boundary. i.e. in my case on the upper and lower sides of the triangle. (for other condition, O.F. did not accept pre-determination of velocity by expressing error)

Many thanks for your kind and always effective hints.

Regards
Bobi

[Hgholami]

Hi wyldckat
I modify transitionalParabolicNonVelocity by replacing

vectorField::operator=(n_*curMeanValue*(1.0 - sqr(coord)));

with

vectorField::operator=(n_*curMeanValue*(1.0 - pow(coord,2)));

and compile successfully. It work fine. But when I change code to

vectorField::operator=(n_*curMeanValue*(1.0 - pow(coord,1.7)));

it compile successfully but in running simulation give error

Floating point exception (core dumped)

. Do you any idea for this?
OpenFOAM-ext4.0, solver icofluid of fsiFoam.

[wyldckat]

Quick answers:

Originally Posted by Hgholami

Do you any idea for this?

The only thing that comes to mind is to try to use "scalar" to convert the value to actual scalar value type that OpenFOAM and foam-extend use:

vectorField::operator=(n_*curMeanValue*(1.0 - pow(coord,scalar(1.7))));

Beyond this, I would have to test it myself, but would need to know:

1. Which installation instructions you followed.
2. Which Linux Distribution you are using.
3. A simple test case with which to reproduce the error.

Originally Posted by Hgholami

OpenFOAM-ext4.0, solver icofluid of fsiFoam.

Please refer to its actual project name: foam-extend

[Hgholami]

Originally Posted by wyldckat

Quick answers:

The only thing that comes to mind is to try to use "scalar" to convert the value to actual scalar value type that OpenFOAM and foam-extend use:

vectorField::operator=(n_*curMeanValue*(1.0 - pow(coord,scalar(1.7))));

Beyond this, I would have to test it myself, but would need to know:

1. Which installation instructions you followed.
2. Which Linux Distribution you are using.
3. A simple test case with which to reproduce the error.

Please refer to its actual project name: foam-extend

Dear wyldckat
I use linux Ubuntu 16.04 with fsiFoam that downloaded from
https://openfoamwiki.net/index.php/E...re_interaction
the tutorial of hron&Turek that exist in fsiFoam folder is uses and transientParabolicVelocity in src folder of this toolkit modified with pow(a,n) (ex. 0<n<1 or any double value).
I use your recommended code but still the problem exist.
I saw in programmerGuide of openfoam that pow(a,n) work with n=0,1,2,..,4.

[wyldckat]

Quick answer: In the custom code you have, see this line?

    // Calculate local 1-D coordinate for the parabolic profile
    scalarField coord = 2*((c - ctr) & y_)/((boundBoxMax_ - boundBoxMin_) & y_);

Add this line after that one:

    Info << coord << endl;

Compile the library again.

Run the case and you should see the list of values for "coord" before it crashes.

See any negative values? If there are negative values, care to guess why the power to 1.7 of a negative value would be a bad idea in the real value spectrum?

If you're not seeing it yet, square root can be defined as a power... "pow(value,0.5)". The cubic root can also be defined as a power: "pow(value,1.5)"

Not seeing it yet? Negative numbers inside root operations will result in imaginary numbers, i.e. not real numbers but instead complex numbers, which is not supported in this particular situation...

[Hgholami]

You are right. the (c-ctr) give negative value. By converting negative values to positive values, the problem solved.
Thanks