Grasshopper

algorithmic modeling for Rhino

Hi,

I am back engineering a steel plate girder bridge to determine improvements to workflow using Grasshopper and (Dynamo) sorry !

I have generated a plate girder profile and have swept it along a curve, R=161m and L=-250m. Hopefully the curve is parameterised.

my workflow is as follows:

Generate girder profile, parametric

Sweep along curve

Bake geometry into GH

My utimate aim is to bake to a wire frame and a surface model for two types of analysis 1. 3D space frame ( grillage) and 2. equivalent finite element analysis.

I noticed that my flange widths Bflt and Bflb (top and bottom) respectively and inverted, they are by all accounts technically upside down, can someone cast soem light on this.

I use Lusas as my analysis package and sweeping a curve or surface will generate the higher order geometry a volume. Does the GH deal with this in the same way.

Finally does the resulting BREP require to be further processed to be baked. Processed to say a mesh? Or something else?

Definition attached, oh! chocolate fish to the person who makes me feel less of a numbskull.

Thanks

Views: 645

Attachments:

Replies to This Discussion

Upside down: you "map" apples to bananas , he he (see attached).

Further processed: er... hmm ... does this goes for FEA?

BTW: can we swap chocolate fish with real fish? (smelly sardines, what else? - if they are aplenty [and in good shape] I could consider providing a little thingy that does I/IPE/HEA/HEB/C/Tube beams in a far more "compact" way).

BTW: bending a "large" IPE (or else) is very expensive - not to mention the join "little" issue (lengths are usually 6000 mm).

Attachments:

Yikes: Focusing to the planes issue I haven't spotted the main thing here > your profiles are not closed  (and/or faulty in some area) ... thus the invalid Brep [rather impossible to bake]... and thus > garbage in > garbage out

Try this:

Many thanks Peter i think i got it.

Baking seems ok now.

Slightly puzzled by the local axis orientation of the PFrame's y axis (green vertically down).
I''ve interpretated this as a 3D xy frame. the 180 reverses the y orientation ie green and the x red, with the z along the curve.

Does the re-orientated PFrame Z axis effectely become the Rot3D cmd's X axis.

Again many thanks

Kenyon

Attachments:

Well ... get this rather primitive thingy attached that does "profiles" - but in fact requires "catalogs" (DataTrees in GH speech) like this:

... and some decent fillet capability (not very easy with Rhino) in order to properly make standard real-life IPN, IPE, HEB, HEA, C ... blah, blah profiles (shown some custom app running in AECSOSim for that matter):

NOTE: profiles are made with the standard Plane that we use when defining instance definitions et all: i.e. Plane.WorldXY meaning that  - if you use it - you must "adjust" the rotations in order to "map" apples to apples.

best, Peter

Attachments:

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service