Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gravity forces switched if reference node is not first node #213

Open
DomIno0o opened this issue Sep 18, 2022 · 4 comments
Open

Gravity forces switched if reference node is not first node #213

DomIno0o opened this issue Sep 18, 2022 · 4 comments

Comments

@DomIno0o
Copy link

Hi,

Describe the bug
If the reference node is not the first node, the gravity force of the reference node is applied to the first node anyway. The gravity forces of the other nodes leading up to the reference node are each shifted by one node.
I observed this with the NonLinearStatic and NonLinearDynamicPrescribedStep solvers.
I don't think that the masses are switched because the modal analysis of my model looks fine. However, I am not sure how to confirm this thought.
The switch affects lumped and distributed masses.

To Reproduce
Choose a reference node other than the first node.
I used the cantilever_wing example and gravity force information given in the paraview beam plot to examine this anomaly.

Expected behavior
The case file page says about boundary conditions: "Usually, the first node has 1" which sounds like nodes other than the first can also be used.

@ACea15
Copy link
Contributor

ACea15 commented Sep 21, 2022

Hi Dominooo,

A quick check reveals the problem might be here:
vdof_fdof; those variables are passed to the XBEAM (Fortran structural subroutines) to deal with the BC; as they are incremented when the first node is not the reference, the info is lost.
XBEAM seems general on this regard so a quick fix there might be all that is needed, it would need testing though. If this is not the case, it will be for the team to decide whether to document that the first node must be the reference or to actually make the changes in the subroutines to allow an arbitrary selection of this node. Do you have strong simulation arguments for introducing this capability? It would be helpful in making a decision...

Thanks, Alvaro.

@DomIno0o
Copy link
Author

Hi Alvaro,

from my understanding by using two beams and aero surfaces you introduce two vortices in the centre. Theoretically, they should cancel each other out perfectly, but in practice this not necessarily the case. If I understood correctly, one of the publications linked on the sharpy homepage also mentiones this ("Realistic turbulence effects in low altitude dynamics of very
flexible aircraft"). By using one continous beam and aero surface I avoid this problem.

@ACea15
Copy link
Contributor

ACea15 commented Sep 30, 2022

Hi Dominoo,

Is your last question related to this gravity forces issue? Anyway, in theory yes but in practice we deal with numerics. You could play with variables such as the vortex_radius in the aerodynamic solvers to see if that helps. I have also experienced this and the easiest solution was to model each lifting surface with the same index in the surface_distribution variable. No compromise whatsoever in what can be modelled.

Regards

@DomIno0o
Copy link
Author

DomIno0o commented Oct 3, 2022

Hi Alvaro,

thanks for your answer. The two questions are related, because the documentation says that beam numbering of aerodynamic surfaces must be continous. For me, this implied that a continous aero surface spanning over two beams is not allowed.
I will model the wings with two beams and try your suggestion.
I cannot think of other simulation arguments for an arbitrary reference node, so a change of the documentation is probably enough.

Regards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants