[nortanapura]

Hello,

I'm currently trying to run an aircraft geometry that a colleague of mine meshed, however, it is too big and I would need to scale it. I recalled that the previous version of SU2 had an option in the .cfg setup file to scale the mesh but I can't find it in the current version. Any help would be appreciated.

Thank you.

[economon]

Hi Nor,

Yes, we did in fact move this capability over into the SU2_DEF module, so it's still available! Please see the tutorial here for a bit of a description (you just need to impose a scale factor other than 1.0): https://github.com/su2code/SU2/wiki/...personic-Wedge. Sorry for any confusion.

Hope this helps,
Tom

[nortanapura]

Hi Tom,

Yes this is exactly what I was searching for. Thank you very much for the help.

Regards,

Nor

[polar]

Hi Tom

I have quite a few meshes in mm and need to convert to m. The MESH_SCALE_CHANGE was very convenient and fast (I guess it was just some internal fiddling with the numbers, not really converting the mesh).
Using the DV SCALE and transforming it is less convenient, one step more and takes quite long even for a 500k tetmesh. While I could live with that the bigger problem is that the transformation creates a lot of negative volumes. It is a quite simple mesh, no prismlayer, so the cells are reasonably small.

How to get rid of that? Any options that one can set for the transformation?
I think for a simple mm to m the algorithm the DV scaling is an overkill (I assume it is based on the scaling stuff for the optimization)

Any other possibility to replicate the MESH_SCALE_CHANGE behavior?
(Currently I am thinking of writing a small script that is just scaling all coordinate values, but I would rather avoid that if possible. Also not sure if I wouldn't run into round-off problems, especially for the meshes with prismlayers.

BR

Michael

[hlk]

Originally Posted by polar

Hi Tom

I have quite a few meshes in mm and need to convert to m. The MESH_SCALE_CHANGE was very convenient and fast (I guess it was just some internal fiddling with the numbers, not really converting the mesh).
Using the DV SCALE and transforming it is less convenient, one step more and takes quite long even for a 500k tetmesh. While I could live with that the bigger problem is that the transformation creates a lot of negative volumes. It is a quite simple mesh, no prismlayer, so the cells are reasonably small.

How to get rid of that? Any options that one can set for the transformation?
I think for a simple mm to m the algorithm the DV scaling is an overkill (I assume it is based on the scaling stuff for the optimization)

Any other possibility to replicate the MESH_SCALE_CHANGE behavior?
(Currently I am thinking of writing a small script that is just scaling all coordinate values, but I would rather avoid that if possible. Also not sure if I wouldn't run into round-off problems, especially for the meshes with prismlayers.

BR

Michael

I believe that the current code assumes that the mesh will be provided either with meters or inches as the unit of measurement.

I think your best bet will be either writing a script or checking out a previous version from github in order to do your processing, (I think that would produce a mesh_out.su2 file, which if you want could be used with the updated version). Since the format can be in scientific notation, for a mm to m transformation there will be no round-off issues.

The SCALE design variable stretches the surface geometry identified by DV_MARKER within the mesh, and then the volume mesh is deformed to match (So it does sometimes encounter negative volumes if the deformation is very large, as would be the case for a *1000 scale). This is not guaranteed to preserve mesh quality, especially for large deformations.

[polar]

Originally Posted by hlk

I believe that the current code assumes that the mesh will be provided either with meters or inches as the unit of measurement.

I think your best bet will be either writing a script or checking out a previous version from github in order to do your processing, (I think that would produce a mesh_out.su2 file, which if you want could be used with the updated version). Since the format can be in scientific notation, for a mm to m transformation there will be no round-off issues.

The SCALE design variable stretches the surface geometry identified by DV_MARKER within the mesh, and then the volume mesh is deformed to match (So it does sometimes encounter negative volumes if the deformation is very large, as would be the case for a *1000 scale). This is not guaranteed to preserve mesh quality, especially for large deformations.

I would also prefer to have all my meshes in m from the beginning, but the CAD is mm based .
Using previous versions probably won't work as they do not seem to transform the mesh but only do the conversion a "runtime".

But your right, the scientific notation should make it quite robust.

They way the SCALE works according to your description confirms my gut feeling at the beginning that it is too powerful and definitively not intended to do a simple unit-conversion scale.

So script it is. Bringing back the MESH_SCALE_CHANGE would be nice, but there were probably some good reasons to kick it

br

Michael

[hlk]

Originally Posted by polar

I would also prefer to have all my meshes in m from the beginning, but the CAD is mm based .
Using previous versions probably won't work as they do not seem to transform the mesh but only do the conversion a "runtime".

But your right, the scientific notation should make it quite robust.

They way the SCALE works according to your description confirms my gut feeling at the beginning that it is too powerful and definitively not intended to do a simple unit-conversion scale.

So script it is. Bringing back the MESH_SCALE_CHANGE would be nice, but there were probably some good reasons to kick it

br

Michael

It may also be worth your time to check if you added all of the boundary markers to DV_MARKER - this was bugging me so I checked on a test case whether a scale factor of 1000 worked using the example Tom linked above, and on a 2D inviscid mesh it took ~1 second to complete.

[polar]

Originally Posted by hlk

It may also be worth your time to check if you added all of the boundary markers to DV_MARKER - this was bugging me so I checked on a test case whether a scale factor of 1000 worked using the example Tom linked above, and on a 2D inviscid mesh it took ~1 second to complete.

Had all the boundaries in the DV marker. Probably the 2d is much simpler than the 3d

[economon]

Hi Michael,

Can you please give this another try with the current version of the code on the develop branch: https://github.com/su2code/SU2/tree/develop

I think it should have the behavior you were expecting now, which I agree is the right way to go (just hadn't gotten to it yet, ).

T

[polar]

Originally Posted by economon

Hi Michael,

Can you please give this another try with the current version of the code on the develop branch: https://github.com/su2code/SU2/tree/develop

I think it should have the behavior you were expecting now, which I agree is the right way to go (just hadn't gotten to it yet, ).

T

It works, conversion is fast, no negative volumes. I had a look at your code, simple scaling of the coordinates . Good to have this in the "official release" rather than use my own script/version. Thanks.