Feature Request/Query: Modeling fully solid cross-sections (Foam Core filling 100% of internal volume)

[stage-be-sketch]

Hi SONATA team,

I am currently working on a wing project and I would like to model a cross-section that is entirely filled with a core material (e.g., foam or solid reinforcement) inside an outer skin.

I have tried using the fixed: core attribute in the YAML configuration. However, when I define a layer that covers most of the arc (from 0.01 to 0.99), I frequently encounter the following issues:

UnboundLocalError: local variable 'U' referenced before assignment in find_BSplineLst_coordinate.

ValueError: data must be of shape (n, m) in fuse_rows (cKDTree initialization).

My questions are:

Is SONATA natively designed to handle a 100% solid core filling?

What is the "best practice" YAML structure to achieve a full-core section without triggering B-spline offset errors at the leading or trailing edges?

Should I use a specific cutoff_style or a virtual web to stabilize the topology for solid sections?

Thank you for your help and for this great tool!

[JustinPorter88]

Are you running SONATA with the WindIO input yaml? I believe that the WindIO yaml for SONATA does not currently support filling sections.

Alternatively, if you run with flag_wt_ontology = False, there is an option using the old TU Munich input deck to fill sections. You can look at this example and the associated yaml file. This is currently on the develop branch.

Trying to define individual layers that go all the way to fully filling the section is likely to run into errors as you have described.

If this does not answer your questions, please post a small example highlighting the issue when running on the develop branch.

Support through the WindIO file for filled sections may be added in future projects.

[stage-be-sketch]

Hi @JustinPorter88 ,

Thank you very much for your feedback!

To answer your first question: Yes, I was previously trying to use the WindIO YAML, and as you suspected, it was struggling with the 100% core filling.

Following your recommendation, I switched to the develop branch and set flag_wt_ontology = False to use the TU Munich input deck. It works perfectly now! The filling sections are correctly handled without any B-spline or coordinate errors.

I will definitely use the 5_UH60 example as a reference for my future models. If I have any more specific questions about the model's architecture in the future, I won't hesitate to reach out.

Thanks again for the great support!

[JustinPorter88]

Glad to hear that it all seems to be working.

[stage-be-sketch]

Hi @JustinPorter88 ,

I have one additional question regarding the outputs. In the earlier version of SONATA, the tool used to export not only the cross-section figures but also two .txt files containing the mechanical properties (stiffness and mass matrices).

In my current setup, I only get the figures. Since these numerical values are essential for my subsequent beam analysis, is there a specific flag or a simple modification I can use to re-enable the export of these text files in the current develop version?

Thank you again for your time and guidance!

[JustinPorter88]

The outputs normally get written when beam_struct_eval is called, but it appears that the UH60 example wasn't using that.

I just pushed a commit to develop that calls that function and adds the flags to the UH60 example to export the two beamdyn input files (.dat files, but they are plain text) and a few csv files.

Alternatively, you should be able to access the data in Python. For spanwise position i at job.beam_properties[i, 0] fraction of length: the mass is in job.beam_properties[i, 1].MM and stiffness in job.beam_properties[i, 1].TS.

Does this give you what you need? There are a lot of different coordinate systems in the code, so please verify that your results match the expected coordinate system.

If you need it, you can find documentation on the beamdyn input deck structure here. Note, that SONATA hasn't yet been updated for OpenFAST 5.0, so is currently missing a section of the beamdyn input for damping that will be added sometime soon.