[MBDyn-users] Best way to get forces from state-space integration into mbdyn?

Pierangelo Masarati pierangelo.masarati at polimi.it
Mon Sep 25 10:30:19 CEST 2017


On 09/18/2017 10:35 AM, Richard Crozier wrote:
>
>
> On 15/09/17 21:38, Pierangelo Masarati wrote:
>> On 09/13/2017 11:21 PM, Richard Crozier wrote:
>>> On 08/09/17 15:59, Richard Crozier wrote:
>>>> Dear List,
>>>>
>>>> I have a set of forces I wish to apply to structural nodes which 
>>>> are the output of the integration of a state-space system. The 
>>>> inputs to this system are the node velocities. The outputs are the 
>>>> hydrodynamic wave radiation forces on a body moving in water waves.
>>>>
>>>> What I am trying to figure out is how to do this state-space 
>>>> integration in tandem with the mbdyn nodal simulation. Is there any 
>>>> way to get MBDyn to do this state-space integration for me?
>>>>
>>>> It seems like the Aeromodal Element may do something like this, so 
>>>> I plan to look at this, but is there a better/simpler way?
>>>>
>>>> Regards,
>>>>
>>>> Richard
>>>>
>>>
>>>
>>> Following on from my previous message, I had a go using the 
>>> state-space MIMO genel to achieve this, which seems like it should 
>>> do what I want however, I can't find an example of this element in 
>>> use and have run into a problem.
>>>
>>> Unfortunately I can't attached the real input file as it is too 
>>> large for the mailing list but you it would not be possible to run 
>>> the input file anyway as it required external socket forces from 
>>> another program. I have attached a version with the state-space 
>>> matrices removed instead.
>>>
>>> When I try to run the file, I get the following error from mbdyn 
>>> (happens when I call GetMotion() for first time which returns -1):
>>>
>>> "StructNode(1): unable to return angles"
>>>
>>> I suspect the problem is in my specification of the inputs and 
>>> outputs, e.g. I have the following genel :
>>>
>>>      genel : 12, state space MIMO,
>>>          6.0, # number of outputs
>>>              1.0, structural, 1, algebraic,
>>>              1.0, structural, 2, algebraic,
>>>              1.0, structural, 3, algebraic,
>>>              1.0, structural, 4, algebraic,
>>>              1.0, structural, 5, algebraic,
>>>              1.0, structural, 6, algebraic,
>>>          6.0, # number of inputs
>>>              node dof, 1.0, structural, 1, differential,
>>>              node dof, 1.0, structural, 2, differential,
>>>              node dof, 1.0, structural, 3, differential,
>>>              node dof, 1.0, structural, 4, differential,
>>>              node dof, 1.0, structural, 5, differential,
>>>              node dof, 1.0, structural, 6, differential,
>>>          187.0, # state order
>>>          Matrix A,
>>>     ... etc. (big matrices)
>>>
>>> I gather from the input manual there is some restriction on what 
>>> node dof values you can use. Essentially I am producing forces for 
>>> all degrees of freedom of a structural node based on it's velocity 
>>> and angular velocity.
>>>
>>> I would really appreciate some help in understanding the correct way 
>>> to do this, if it is possible. 
>>
>> At a first glance, I don't know if there's a cleverer way to do it, 
>> apart from writing a dedicated user-defined element.
>>
>> There seems to be a misunderstanding in what you're trying to do. 
>> What can surely be done (but would be rather inefficient) is 
>> something like this:
>> - define 6 x N abstract nodes
>> - use these 6 x N abstract nodes as the output of the MIMO element
>> - define N "total" force elements, which use the corresponding 6 
>> abstract nodes as force and moment components through the "node" 
>> drive caller.
>>
>> Something like:
>>
>> begin: nodes;
>>      # ...
>>      abstract: 1;
>>      abstract: 2;
>>      abstract: 3;
>>      abstract: 4;
>>      abstract: 5;
>>      abstract: 6;
>>      abstract: 11;
>>      abstract: 12;
>>      abstract: 13;
>>      abstract: 14;
>>      abstract: 15;
>>      abstract: 16;
>>      # ...
>> end: nodes;
>>
>> begin: elements;
>>      # ...
>>      genel: 12, state space MIMO,
>>          6*2,
>>              # forces on node 1
>>              1, abstract, algebraic,
>>              2, abstract, algebraic,
>>              3, abstract, algebraic,
>>              # moments on node 1
>>              4, abstract, algebraic,
>>              5, abstract, algebraic,
>>              6, abstract, algebraic,
>>              # forces on node 2
>>              11, abstract, algebraic,
>>              12, abstract, algebraic,
>>              13, abstract, algebraic,
>>              # moments on node 2
>>              14, abstract, algebraic,
>>              15, abstract, algebraic,
>>              16, abstract, algebraic,
>>          6*2,
>>              # velocity of node 1
>>              drive, 1, structural, string, "XP[1]", direct,
>>              drive, 1, structural, string, "XP[2]", direct,
>>              drive, 1, structural, string, "XP[3]", direct,
>>              # angular velocity of node 1
>>              drive, 1, structural, string, "Omega[1]", direct,
>>              drive, 1, structural, string, "Omega[2]", direct,
>>              drive, 1, structural, string, "Omega[3]", direct,
>>              # velocity of node 2
>>              drive, 2, structural, string, "XP[1]", direct,
>>              drive, 2, structural, string, "XP[2]", direct,
>>              drive, 2, structural, string, "XP[3]", direct,
>>              # angular velocity of node 2
>>              drive, 2, structural, string, "Omega[1]", direct,
>>              drive, 2, structural, string, "Omega[2]", direct,
>>              drive, 2, structural, string, "Omega[3]", direct,
>>          187, # state order,
>>              Matrix A,
>>                  # big matrix...
>>          ;
>>
>>      force: 1, total,
>>          1,
>>              force, component,
>>                  node, 1, abstract, algebraic, direct,
>>                  node, 2, abstract, algebraic, direct,
>>                  node, 3, abstract, algebraic, direct,
>>              moment, component,
>>                  node, 4, abstract, algebraic, direct,
>>                  node, 5, abstract, algebraic, direct,
>>                  node, 6, abstract, algebraic, direct;
>>      force: 2, total,
>>          2,
>>              force, component,
>>                  node, 11, abstract, algebraic, direct,
>>                  node, 12, abstract, algebraic, direct,
>>                  node, 13, abstract, algebraic, direct,
>>              moment, component,
>>                  node, 14, abstract, algebraic, direct,
>>                  node, 15, abstract, algebraic, direct,
>>                  node, 16, abstract, algebraic, direct;
>>      # ...
>> end: elements;
>>
>> (note: untested!)
>>
>> Sincerely, p.
>>
>
>
> Thanks, I thought I might need to do something like this. I wonder if 
> I really need to use a string drive for all of the MIMO inputs, or can 
> I mix in node dof's for components 1, 2 and 3? I will experiment with 
> doing this and report back to the list on the results.
The "string" in the syntax I proposed has nothing to do with the 
"string" drive caller (I know, it is misleading).  "string" in this 
context means that you use the string form to select the node's datum.  
Apart from this, you need to connect one by one each of the "input 
channels".
>
> The only problem with this is that actually I have presented only the 
> simple case where there is no body-to-body interaction. With body-to 
> body interactions the radiation force on each body actually depends on 
> the velocities of every body.
In that case, things get weird, but you can still combine each node's 
contribution (easier if linear, so all you need to do is a constant 
matrix B times all the input channels).
>
> For anyone interested, below is some more information on exactly what 
> I am doing, anyone else can stop reading now!
>
> To give more explanation, I am solving the radiation forces on a 
> floating body in water. These forces depend on the time history of the 
> body's motion. One way to calculate the forces is to use a convolution 
> integral, see here:
>
> http://wec-sim.github.io/WEC-Sim/theory.html#convolution-integral-formulation 
>
>
> but it can be linearised to a state-space system, which is the form I 
> want to solve in MBDyn (also described at the link above). Actually I 
> could solve this outside of MBDyn in Matlab/Octave (I do the 
> convolution method this way), but since MBDyn controls the integration 
> time stepping this is awkward to do robustly for the state-space 
> integration.

Good luck!


Alternatively, consider creating a user-defined element that does 
something more similar to what you need.


Sincerely, p.



-- 
Pierangelo Masarati
Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano



More information about the MBDyn-users mailing list