[MBDyn-users] Some questions regarding structural internal forces.

Pierangelo Masarati masarati at aero.polimi.it
Fri Jan 16 23:49:04 CET 2009

Rudi Jaeger wrote:
> Dear Dr. Masarati,
> I am trying to use structural internal forces. My first problem is that the .frc-output-file
> contains 12 colums though the input manual suggests that there are only 9.
> Based on the input file listed below, colums 7-9 and 10-12 are the locations
> where the forces are being applied.

yes, the locations with respect to the first and the second node, 

> Why is the information in colums 10-12
> listed this way?

I do not recall, honestly.  Actually, I'd regard that format as 
obsolete, as I plan to entirely replace it with the NetCDF based output 
at some point.  What makes me a little bit reluctant yet is the fact 
that NetCDF would become a prerequisite rather than an option.

> Shouldn't this information go into a separate line, starting
> with the appropriate node number?

Well, in my intention, each line should correspond to an element.  The 
current format is consistent with it.

> The forces (just on node1) - colums 4-6 - are listed in a local coordinate system.
> Right?

No.  The force is in the global reference frame, as well as the offsets. 
  They represent the distance between the application point and the 
respective node, projected in the global reference frame.

> As far as I can see, there is no way of updating the direction of the forces. So
> constructions like:
>     force: 
>         f_rod01, 
>         absolute internal,
>         n_base01,
>         model::xdistance(n_base01,n_body01),
>         model::ydistance(n_base01,n_body01),
>         model::zdistance(n_base01,n_body01),
>         null,
>         n_body01,
>         null,
>         const, 2.0;
> will not lead to internal forces that will always act in the direction
> of a straight line that connects both nodes.

This is correct: you're using the model namespace to extract information 
that is evaluated when the input is read, so there is no way it can be 
updated run-time.

> Or do I understand something wrong?

If you need the magnitude or the direction of the force to be computed 
based on model configuration data evaluated run-time, you need to use 
drivers that evaluate this information run time.

This is not straightforward right now, as the force element uses a fixed 
direction and only allows to parametrize the magnitude (as far as I recall).

As a rather inelegant solution, you can use three separate force 
elements, one for each component.  Or, as an alternative, since you want 
   the force to act along the line that runs through the two nodes, you 
could use a rod with a custom constitutive law that actually results in 
the force you want to obtain.

As an alternative, you could modify the force element family so that it 
takes a parametric Vec3 (TplDriveCaller<Vec3>) instead of a Vec3 and a 
DriveCaller.  I believe this would be an optimal solution, although it 
would probably not allow to preserve 100% backward compatibility with 
the current input format, since parsing the TplDriveCaller<Vec3> would 
require to first read direction and magnitude, and then read the arm, 
while now MBDyn first reads the direction, then the arm and finally the 

If this were available, your model would be something like

          absolute internal,
          n_base01,	# node 1
          null,		# node 1 arm
          n_body01,	# node 2
          null,		# node 2 arm
          component,	# three components as separate drives

I'd try to code it myself if I had time, but I can't promise anything in 
the very near future.

Sincerely, p.

More information about the Mbdyn-users mailing list