VAWT workflow

[cesarj.95plus]

Dear support, I am strugging to follow the following workflow:

1. Define named surfaces with shared topology in spaceclaim
2. Mesh the geometry in Fluent meshing
3. Set the slidding grid in Fluent solver

Do you know any good tutorial with spaceclaim + fluent (mesh and solver?)

[cesarj.95plus]

I leave here my progress up to now:

As you can see, I have named the internal and external edges and used shared topology so Fluent meshing admits the geometry:

However these edges don't appear for the mesh inteface creation even though the appear as a "wall" boundary condition I tried to preview the mesh motion but even if the mesh is sliding, there are 2 points that travel with the mesh (which are construction vertex in the CAD):  

I am a bit confused with the grouping that spaceclaim does because even if I set everything into a single named selection, it appears as a deconstructed entity in Fluent, the shared topology edges don't appear anymore for mesh interfaces elections and there isn't a clear way to set the right connectivity.

[Rob]

Share Topology will connect the two sides of the non-conformal, so you're then likely to twist the mesh. I can't see the first image but assume you have wall & shadow pairs? This is one of the few times you don't use Share Topo, but it's fixable in Fluent if it's too big a task to go back to geometry.

Either set up all of the motion as frame motion and then convert to moving mesh.

OR

Have a look in the TUI for

/mesh/modify-zones/slit-...    

Then give Fluent the surface ID of one of the wall or shadow faces.  I can't remember the rest offhand and can't launch Fluent whilst I'm updating my laptop.  From there you can manually create the sliding interface zones. 

[cesarj.95plus]

Thank you Rob for you reply.

Using shared topology was the only way to import the geometry into Fluent Meshing 2D in this case. Therefore I would like to try to solve the problem directly in Fluent Solver.

Sorry for the bad resolution, I've just noticed it now. Indeed I have the following shadow pairs:

interface_rotating_zone_ext:interface_rotating_zone_int.2-shadow
interface_rotating_zone_ext:interface_rotating_zone_int.1-shadow
airfoil_2_interface_ext:airfoil_2_interface_int.2-shadow
airfoil_2_interface_ext:airfoil_2_interface_int.1-shadow
airfoil_1_interface_ext:airfoil_1_interface_int.2-shadow
airfoil_1_interface_ext:airfoil_1_interface_int.1-shadow
airfoil_3_interface_ext:airfoil_3_interface_int.2-shadow
airfoil_3_interface_ext:airfoil_3_interface_int.1-shadow
airfoil_3_interface_ext:airfoil_3_interface_int.1
airfoil_3_interface_ext:airfoil_3_interface_int.2
airfoil_1_interface_ext:airfoil_1_interface_int.1
airfoil_1_interface_ext:airfoil_1_interface_int.2
airfoil_2_interface_ext:airfoil_2_interface_int.1
airfoil_2_interface_ext:airfoil_2_interface_int.2
interface_rotating_zone_ext:interface_rotating_zone_int.1
interface_rotating_zone_ext:interface_rotating_zone_int.2

The reason of having 2 curves per circle is due to the way my CAD uses semi arcs to represent circles and this unfortunately creates 2 edges per circle.

I've tried both approaches:

A) I've tried to use /mesh/modify-zones/slit-periodic (which is the only /mesh/modify-zones/slit-... option that I could find) and I have an error because they aren't periodic boundary conditions:

Error at host: split_periodic: zone 82 is not periodic

 

Error: split_periodic: zone 82 is not periodic

Error Object: ()

 

Error at Node 0: split_periodic: zone 82 is not periodic

 

Error at Node 2: split_periodic: zone 82 is not periodic

 

Error at Node 3: split_periodic: zone 82 is not periodic

 

Error at Node 1: split_periodic: zone 82 is not periodic

 

Error: split_periodic: zone 82 is not periodic

Error Object: #f

Is this the correct command?

B) I have also tried to set the frame motion and then setting the same values in the mesh motion but the unwanted displacement of 1 node still occurs:

[Rob]

/slit-face-zone

 

That should detach the nodes as well as the facets. Otherwise set up with frame motion and then copy to mesh motion (you'll need to turn on/off frame & mesh options)

[cesarj.95plus]

I see, maybe since I am using pyfluent (and ANSYS student 2025R2) that option isn't reachable (yet) from session.settings.mesh.modify_zones method. The only methods available are the following ones:

['deactivate_cell_zone', 'delete_cell_zone', 'copy_move_cell_zone', 'copy_cell_zones_by_offsets', 'copy_cell_zones_by_delta', 'list_zones', 'extrude_face_zone_delta', 'extrude_face_zone_para', 'fuse_face_zones', 'scale_zone', 'rotate_zone', 'translate_zone', 'merge_zones', 'replace_zone', 'append_mesh', 'append_mesh_data', 'sep_cell_zone_mark', 'sep_cell_zone_region', 'sep_face_zone_angle', 'sep_face_zone_face', 'sep_face_zone_mark', 'sep_face_zone_region', 'zone_name', 'change_zone_state', 'make_periodic', 'create_periodic_interface', 'slit_periodic', 'zone_type', 'del_cell_by_id', 'del_cell_by_mark', 'disconnect_cell_zones', 'project_face_zones']

Regarding the copy of frame motion to mesh motion, I did the following steps:

1. Toggled ON "Frame motion"
2. Filled the "Reference Frame" tab
3. Pressed the "Copy to Mesh Motion" buttom
4. "Mesh motion" is activated, the values are moved to the "Mesh Motion" tab and "Frame motion" is toggled OFF

Unfortunately the same problem occurs:

 

[Rob]

Inwhich case you'll need to do the set up from the TUI or GUI. A last (messy) option is to mesh the outer zone in one session, the inner zone in a separate session and then use Append Mesh in Fluent. You will have to manually set the non-conformal interface up. 

[cesarj.95plus]

I see. Would it be a good idea to use the region type and save each zone by separate to avoid doing 5 different sessions leading to a non-conformal mesh? I could set the region that I want to save as "fluid" and the rest "dead" and do the process 5 times:

Or would it be better to:

1. Do the main_fluid grid in one session and save the grid
2. Load the main_fluid grid to create the rotating_zone grid having a conformal grid (is this even possible?)
3. Repeat step 2 with the rotating zone for each airfoil region

I would love if the second approach is possible as this would mean that I could build modular meshes to introduce local changes without remeshing the whole fluid again :)

[Rob]

The second approach works. Basically, mesh each zone (dead is a neat trick) and export. In Fluent you can delete/append mesh zones so the settings will be retained in the case but you can add/remove lumps of mesh. It's actually a very old trick for building meshes that are too big for one computer: we'd build 500k cells, export, delete, mesh the next 500k cell section etc. Mind, your phone has more compute power than my (very) old desktop..... 

Just be careful with labels and use 26R1 or don't delete air & aluminium from the materials list. I won't be expanding on the last point. 

[cesarj.95plus]

I see, and this approach works only for 3D geometries? My fluent meshing session freezes when I try to load a 2D mesh and if I load a 3D mesh I cannot load a CAD geometry later on to continue the grid. Is there any tutorial to show an example of this in Fluent meshing?

[Rob]

Should work for 2d in Fluent, I'm not sure about Fluent Meshing. The latter has a 2d workflow but I've not used it. 

[cesarj.95plus]

I have more questions about it but it feels like we are going off-topic now. I've create another topic to talk abour this issue ( https://innovationspace.ansys.com/forum/forums/topic/modular-mesh-in-fluent-meshing/ ) and once this is fixed we can talk again about the VAWT workflow. Please feel free in intervene in the topic!

[Rob]

I'd seen it - I know how to do it in (very) old school TGrid but not with Fluent Meshing's workflows. I'll "remind" the moderator group that they need to do something: I'm a Forum Moderator as opposed to handling any resourcing. 

[cesarj.95plus]

Hi again

I've finally decided to go for a sliding grid approach and I have found the following ANSYS tutorial: https://innovationspace.ansys.com/courses/courses/vertical-axis-wind-turbine-part-1/lessons/physics-setup-lesson-4-2/

However, when I try to apply the same method I have the following error when displaying the grid motion:

However it works when I set all the zones to rotate around the same point and relatively to the main fluid:

 I am a bit confused about why the tutorial approach doesn't work in my case :(

 

[Rob]

It should. Double check the region definitions. The larger rotating zone should be absolute, and the three blades each have a unique axis and move relative to the larger zone. The "outer" region has no rotation. 

Right click on the cell zone top level menu in the tree and "show modified settings" as that may show what's causing the problem. 

[cesarj.95plus]

I see, so this is the modified settings summary in the case that works:

But the mesh motion crashes with the following set up where I define a local rotation axis for each airfoil:

The values should be quite precise as I set them using the values from operations with numpy:

# WT key dimensions
x0_mm = 4.5
arm_mm = 30
chord_mm = 25

# Rotational speed
omega_rpm = 60
omega = omega_rpm / 60*2*np.pi

# Obtain coordinates of rotation center (Xrot_center) and local airfoil centers (airf*_m)
Xrot    = [x0_mm/1000, 0]
airfX_m = [(x0_mm + arm_mm * np.sin(np.deg2rad(ang)))/1000 for ang in [0, 120, 240]]
airfY_m = [(    0 + arm_mm * np.cos(np.deg2rad(ang)))/1000 for ang in [0, 120, 240]]

[Rob]

What's the rotation speed in the second case?

[cesarj.95plus]

In both cases is the same, 60rpm (6.28 rad/s) but the moving mesh rotation speed isn't displaye when it is set to 0 (like some other values). In the second approach, I set to 0 the rotational speed of the airfoils because they don't move with respect the rotating zone but this seems to lead to an error.

[Rob]

I think they do move as they have a centre of rotation and are set relative. 

[cesarj.95plus]

I see, that means that the center of rotation of each local airfoil should be moving with time and I should provide a time dependent expression. Well I guess that for this simple case I can just set everything to absolute and it will work.

I've also tried to set them as fixed to see if they would be carried with the rotating zone but didn't work obviously:

[Rob]

No need as it's moving using the axis defined at the start. The above is what happens when centre or relative motion definition gets messed up as you noted. When we wrote the first version of the tutorial for about v6.3 using a UDF any errors tended to result in the blades orbiting the hole in the mesh and every 1/4 cycle or so they'd catch up to exchange air: very pretty but not overly useful. 

[cesarj.95plus]

I see so the initial defined axis should move if the relative position of the blades is defined with respect the rotating zone. Unfortunately this isn't working for me... Do you have any other ideas to debugg this issue? (i.e. look into the cell zone types or similar?) This topic is quite new for me and I really appreciate your support with all these messages.

[Rob]

Check the rotation axis for the three blades, you've set those to be all different. But, was that the correct positon at t=0s? If you've run a bit to and seen an error re-initialising may not revert the mesh position. 

[cesarj.95plus]

I set them differently because it is said so in the tutorial that I've mentioned in the past(https://innovationspace.ansys.com/courses/courses/vertical-axis-wind-turbine-part-1/lessons/physics-setup-lesson-4-2/):

But for some reason it is not working for me:

[cesarj.95plus]

Okey I've found the issue, I had this in the past in another software but I am leaving it here in case someone runs into the same issue.

I was computing the locations using python trigonometry relations which use a HUGE amount of decimals as you can see in the previous reply. In CATIA the mm accuracy is about 3 decimals so I decided to try the same:

So rounding my floats to the same number of decimals (3 for mm and 6 for m) like this makes it work:

However I have this Note, how bad is it?

[Rob]

Thanks for posting. Are you running double precision? Even so I'd not expect that to be too much of a problem. 

They're warnings. When Fluent creates and updates a non-conformal a wall and interior are also added in the background. If the two side of the interface line up the interior is available, if they don't the wall stops flow "falling out" of the domain. As they don't technically exist as surfaces you can't display them. If you right click on the Mesh Interfaces header in the tree (possibly a level lower) there should be a report overlap or similar - that'll tell you if you've got a properly connected interface pair. 

[cesarj.95plus]

That is very helpful, I will keep that in mind and thank you very much for your assistance along this thread!

[Rob]

You're welcome. Good luck with the rest of the model.