probe planes with voids

[gamemakerh]

Hi.

I encountered with the problem when I want to probe plane with voids. post processing representation is strange.

NaN values are represented as -1000000000000000000000000000 or 100000000000000000000000000 numerical values. Paraview just filter this values as NaN and do not include into graphical representation. Butterfly do not have ability to filter voids. I've managed to make custom filtering procedure, but it's kinda labor required procedure. maybe in the future it would be possible to make NaN values (voids) be excluded from post processor ?

[TheodoreGalanos]

Hi @gamemakerh

This is a well known issue for some time now. In all honesty I'm not sure it is a BF bug, since this is smth that happens within OF when we try to sample outside of our domain.

The easiest solution, which should be quite fast as well, is to split the surface itself and only allow the areas within the domain. Splitting (with voids, if required) and scaling down by 5% would ensure the above doesn't happen, provided your cell size is smaller than that 5%.

Another quick way to do it is to use the cull pattern component and a larger than component, in order to remove any value above e.g. 30 m/s (or any unrereasonable value).

I think in the future we are planning to include the ability to do this within BF but I can imagine it might be hard to eliminate every scenario where this happens. I think the best approach is to adopt the above as a good practice.

Hope all this helps.

Kind regards, Theodore.

[mostaphaRoudsari]

Hi @gamemakerh and @TheodoreGalanos,

Butterfly actually has the methods to deal with skipped probes. However I removed it from the final release. The reason was that Butterfly loads the results every couple of seconds and adding an extra check for skipped points each time wasn't efficient. In case of ParaView it does load the results once for each time and removing the NAN values is easy.

Since this has been causing issues for users maybe we should at least have it as an option.

[gamemakerh]

@mostaphaRoudsari thanks for explanation.

one more thing...

HOW TO DEFINE GRAVITY IN BF ???

i mean if I want to change direction of gravitational vector. where I should constrain this setup ?

I've changed g.py but maybe there is different way ?

[mostaphaRoudsari]

@gamemakerh, that's the right file. please open a new issue for this or post a topic on discourse.ladybug.tools

[TheodoreGalanos]

@gamemakerh I'll just post this here since it's quick. there is a file in the constant folder called g. In there, gravity is defined by a vector as follows:

dimensions      [0 1 -2 0 0 0 0];
value		(0 0 -9.81);

You can easily change the vector, or even gravity itself, to your liking.

Kind regards, Theodore.

[mostaphaRoudsari]

You mean from the Grasshopper interface? You can use the solution parameter component to edit the value inside the g file. Otherwise as I mentioned in the previous response the default values are set inside g.py and here are the lines to modify the value if you want to edit the source code. Again I suggest to open a new issue for this and we can discuss this in more details if this doesn't answer your question.

[gamemakerh]

Thanks guys. I've opened new issue.

[MingboPeng]

Hi @TheodoreGalanos @mostaphaRoudsari ,

Is this gravity setting correct?

This is from the OpenFOAM tutorial file:

Same from https://cfd.direct/openfoam/user-guide/v6-dambreak/

Thanks, Mingbo

[mostaphaRoudsari]

Most likely in OpenFOAM sample file Y and Z axis are swapped. That's the norm for engineering tools. In our case we keep the axis the same as the 3d model in Rhino. That's why the two are different.