Many thanks for your comment and questions.

On your second question, consider inputting the data via the script facility (so linking directly to your spreadsheet calculations) or using text format data files (.yml). With text format data files you can use the IncludeFile facility so that your .yml file only has the changes you want to make, so it is easier to QA. Quite a few clients take advantage of the text file format to print off a file that they can read and annotate away from the computer in order to review the input data. This option would also satisfy those QA procedures that require a signed-off paper copy of a file. If you look into this kind of procedure, it would be worth obtaining a text editor that 'understands' the YAML format - we recommend the free Notepad++.

On your first question, I imagine that you are modelling a complex structure using a 6d buoy with other objects (e.g. single-segment lines) attached to it to give the right distribution of mass, drag, added mass etc. A useful OrcaFlex technique for checking a compound object like this is to clamp it rigidly to a vessel, using a very stiff single-segment line, and clamp it so that the object origin is at the vessel origin. The connections loads on the vessel will then tell you various useful things about the properties of the compound object.

The clamp line should be single-segment, include torsion, have all the connection stiffnesses set to Infinity, and have line type properties that give it very high stiffness (e.g. 1.0e10 for bending, axial and torsional stiffnesses) but otherwise zero properties (or 1e-10 for those that aren't allowed to be zero). This gives you a clamp that holds the buoy to the vessel pretty rigidly, and so transmits all the buoy loads to the vessel, but doesn't add any extra loads of its own. And with suitable connection angles you can clamp the buoy at any given orientation you want.

Here are some examples of things you can check using this approach:-

- If you place the vessel such that the object is in air, then the statics results vessel connection force will be in the global Z direction and will equal that total weight. And the X and Y components of connection moment, when divided by that weight, will tell you the horizontal offset of the CG from the vessel origin (and therefore also from the buoy origin). This gives you the x and y offset of the CG. To get the z offset, you can turn the object through 90 degrees (adjusting the clamp connection angles to match), so that the object is now clamped to the vessel with its z-axis horizontal, so that the X or Y connection moment (divided by weight) now tells you the CG z offset.

- You now cancel out the weight force by applying to the buoy a global applied Z-force upwards equal to the weight and applied at that CG. If you then you place the vessel so that the object is fully submerged in the water, then the connection load will now tell you the buoyancy force, and again the X and Y components of connection moment, when divided by the buoyancy, will tell you the offsets of the centre of buoyancy from the origin.

- You can do similar things with drag and added mass, by running a short simulation with the vessel given a suitable simple motion and then looking at the time histories of vessel connection loads. For example you can set the vessel to have Prescribed Motion and give it either a Constant Speed of 1m/s (for analysing drag) or a Speed Change that gives a constant acceleration of 1m/s^2 (for analysing added mass).

- You can check moments of inertia in a similar way, by using vessel Harmonic Motion to give the vessel some angular acceleration about the vertical. This time the connection loads will vary harmonically, but you can take the results at a given time and divide by the vessel angular acceleration at that time. (You should use a short time step for this, but the simulation can be quite short and so very quick.)

I hope these suggestions help. If you'd like clarification, then email orcina@orcina.com for support.

Since an OrcaFlex model can be complex with many components and properties, it may contain hidden errors that can have big effects on the model's behavior or loads. Plus the user can accidentally enter a wrong value. Can you please recommend:
1) Some basic reality checks that should be performed on any completed model, such as turning off the environment and checking the model's still water draft
2) Some methods to extract and document all the user choices that went into the model, such as a routine to generate a report on the dimensions and properties of each model component

Also is there a way to display or calculate the CG of a model made up of many components, rather than the CG of each component?

Thanks!

It's hard for me to say what a third party means by "relative chain diameter". Is it possible that you could ask the third party in question.

However, as Sarah stated in an earlier response, if you can find from your test data, the actual value of "relative chain diameter" assumed in the test then you can enter that value as the "normal drag area" in OrcaFlex and use your Cd = 2.2-2.6 directly.

Please let us know if this doesn't help you solve your problem.

Sorry to re-open this thread but I have a similar question as Ika.
I also have test data where the drag coëfficiënt equals 2.2-2.6, the drag area it was based on was calculated by the 'relative chain diameter' times the length. Here lies my problem, I can't seem to find what they mean by 'relative chain diameter'. Is this the diameter of a rod of metal in the link or rather the width of the entire link?

Could anyone help me with this please?

Thank you,
Bruno

Thanks a lot for your comments. I think we will get around to doing this, but perhaps not in 9.4!

It's hard to say what's going on here without seeing your input file.

If you e-mail it to us then we'll take a look.

Cheers, David.

I'm encountering a new problem with one of the input files. It's something like this, I ran an input file > saved its simulation (and also it's input) > closed Orcaflex > then opened the input file later to show it to my colleague > but this time, though it says "statics complete", it shows a different profile. The file is typically a catenary check with an umbilical passing over a chute. What I try to say by different profile is that, this time, it slides out of the chute (which is not a proper modeling) whereas initially it showed a smooth profile passing along the radius of the chute (which I had saved).

Then I got a new thought. I opened the simulation file (that had the smooth profile), pressed "F12" so that now the simulation file is a "data" file. I ran it in the same window, but it again showed the umbilical with the improper profile.

Can you please get back to me on this and advise as to what could be the reason for this?

Cheers
Senthil

As far as I can tell Google SketchUp uses an un-documented proprietary file format. This means we have no way of working out how to import such a file other than reverse engineering it - and I doubt we'd be very successful at that.

This is symptomatic of a wider issue which is that, as far as I know, there is no standard for 3D modelling files. Every package/technology uses its own proprietary file format. Even worse, these files change from one version of a package to the next.

We have taken the simplest approach possible which is to use the native format of DirectX which is the .x file.

Perhaps the best route for you, if you want to use SketchUp is to export from SketchUp to something like .3ds and then convert that into .x with PolyTrans. However, I think you'd need the Pro version of SketchUp.

I'm sorry we can't be more helpful but I really don't think we can do much more without there being a published standard for 3D modelling files.