As mentioned in a recent post here, we are going to publish a series of articles introducing some of the new features being developed for release in version 10.2. This article is the first of that series, discussing a new vessel option that allows users to make a choice between two methods for the interpretation of diffraction analysis data.
Continue reading “Upcoming in OrcaFlex 10.2: Vessel calculation mode”
Mooring line fatigue damage normally considers only tension load cycles. However, sometimes the mooring chain immediately adjacent to the fairlead (the ‘Top Chain’) can experience significant in-plane and out-of-plane bending which causes additional fatigue damage.
BV guidance note Fatigue of Top Chain of Mooring Lines due to In-plane and Out-of-plane Bendings, [NI 604 DT R00 E, Aug-14], (‘BV note’) describes a Top Chain fatigue damage assessment procedure which includes both tension and bending. Here we describe how to derive the necessary OrcaFlex results to use with the procedure outlined in the BV note.
In the past we have not been very expansive about our development plans for OrcaFlex – usually nothing more than a short bullet list on our website. We’d like to engage more with our users about upcoming OrcaFlex developments. This post is intended to kick-start us in that direction.
But before we get into the details, here are some points that might be useful background:
In terms of individual functionality changes (both additions and removals), our software team plan to blog more about these on other occasions. This post summarises our planning process and states where we are currently with our plans for version 10.2 and beyond.
Continue reading “OrcaFlex Development plans for 10.2 and beyond”
OrcaFlex is primarily used in the offshore oil and gas industry, typically for installation analysis and in-place design of riser and mooring systems, pipelay analysis, field construction, etc., as well as being widely used in the oceanographic community. However, OrcaFlex is an extremely versatile package, and over the years we have seen it used for the global dynamic analysis of a wide variety of applications. Starting what will be an occasional series of blog postings about less common applications for OrcaFlex, we kick-off with a summary of these.
OrcaFlex has a number of features that take advantage of the Python programming language. We work hard to ensure that OrcaFlex is compatible with a wide range of Python versions. However, a couple of recent Python releases have contained bugs that have broken functionality that OrcaFlex relied upon.
Because of these problems we recommend that you do not install either of these versions of Python. If you must use a version from the 2.7 family then we would recommend 2.7.12.
Update: Since this post was originally written, version 2.7.14 has been released which addresses both of these problems.
Python 2 is now maintained only to add bug fixes, and mainstream development attention for Python is given to Python 3. The problems that we have encountered with 2.7, as described above, lead us to recommend that an up-to-date Python 3 should be used with OrcaFlex if at all possible.
Python 3.6 has very recently been released and the next minor update to OrcaFlex, version 10.1c, will support this.
A year has elapsed since we released OrcaFlex 10.0, which means that it is time for the next version. We are very pleased to announce the 2016 release of OrcaFlex, version 10.1.
The software was finalised and built on 19th October. We are currently preparing the installation program, and will then dispatch the software. All clients with up-to-date MUS contracts should receive the new version early in November.
Version 10.1 introduces much new functionality, including:
These are the most significant developments, in our opinion. As always there are a great many more enhancements which are documented in the What’s New topic for 10.1.
What follows is a brief introduction to each of the new features that we consider to be of most significance.
Constraints are a new type of object that provide an enhanced, versatile means of connecting objects. They can be used to:
Constraints were developed primarily to enable simpler modelling of the following:
This list is not intended to be exhaustive. Constraints can be applied in many other situations.
A constraint object comprises two frames of reference: the in-frame and the out-frame. The in-frame is rigidly connected to a master object and therefore translates and rotates with the master object. Slaves of the constraint are rigidly connected to the out-frame and so translate and rotate with the out-frame. The out-frame can translate and rotate, independently in all six DOFs, relative to the in-frame, and it is this capability in particular that makes constraints so versatile and useful.
Typically, a constraint object will be used as a means to connect objects together. The constraint is connected to a master object (e.g. vessel, buoy, line, etc.), and has one or more objects connected as slaves. Constraint objects themselves have no physical properties such as mass or volume, and do not attract hydrodynamic or aerodynamic loading. Their utility is derived entirely from the out-frame’s ability to move relative to the in-frame.
There are two distinct modes of operation for constraints, Calculated DOFs and Imposed displacement. These two modes offer different ways of controlling the relative movement between the out-frame and the in-frame.
Individual DOFs, three translational and three rotational, can be either calculated or fixed, as determined by the input data. For example, to specify a single rotational degree of freedom, about the local y-axis, as would be used to model a hinge, the input data would look like this:
The column of check boxes titled Free is used to specify which DOFs are free and which are fixed. Different settings for these check boxes allow different types of connection to be modelled. For example, to model a telescoping joint you would make a single translational DOF be free.
To demonstrate how the above data models a hinge, the animation below shows the constraint, with a buoy attached to provide mass, acting as a pendulum. The axes drawn with a solid pen represent the in-frame, fixed to global. The dashed axes represent the out-frame. The single degree of freedom is Ry, rotation about local y, where y is normal to the view.
Prior to the introduction of constraints, there were a variety of standard workarounds that could be used to model hinges, articulations, telescoping joints etc. For instance, hinges would usually have been modelled using very stiff single segment lines. But these workarounds were often tricky to build, and sometimes caused numerical problems. With the advent of constraints these issues become a thing of the past.
In addition, calculated constraints also allow specification of stiffness and damping, which can be linear or nonlinear. These properties can be used to resist displacement and velocity of the out-frame relative to the in-frame. Further, applied loads can be specified (constant, time varying, or externally calculated) and applied to the out-frame.
The original motivation for constraints was the Calculated DOFs mode. However, as that feature took shape we realised that these objects could be useful for other forms of connection / constraint. Thus were Imposed Displacement constraints born.
Before this release, the only object capable of imposing motion (as opposed to calculating motion) was the vessel. This could be done through prescribed motion, time history, or external calculation. Although it feels odd to use an OrcaFlex vessel as a means to impose motion, that sort of trick is quite common in OrcaFlex. However, the real weakness is that vessels cannot be connected as slaves of other objects. Constraints have no such limitation.
When imposed displacements are used, the displacement of the out-frame, relative to the in-frame, is specified by time history. All 6 degrees of freedom can be varied, or indeed any subset of the degrees of freedom.
There are many scenarios where imposed displacement constraints are useful. The ability to connect objects together in chains allows multiple imposed displacement constraints to be connected together to form a compound imposed motion. An example where that is especially useful is to model crane operations, as shown in this video:
Having given pre-release demonstrations of constraints to many users over the past few months, I can safely say that they have generated more excitement than any new feature since we added the implicit time domain solver. We hope you have as much fun with them as we have had!
In version 10.0, frequency domain dynamic analysis was added. This was the result of a huge development effort, and the sheer size of the program meant that some features were not initially supported in the frequency domain. The most important of these omitted features was calculated vessels. In version 10.1 we have addressed that omission and OrcaFlex now supports calculated vessels in the frequency domain.
There are really two distinct parts to this development, wave frequency and low frequency. The frequency domain functionality in version 10.0 caters for first order wave loading, what we refer to internally as the wave frequency solver. Extending this functionality to support first order wave load RAOs on vessels is relatively straightforward, and fits into the existing program quite naturally.
While enhancing the wave frequency solver to support calculated vessels presented few challenges, implementing low frequency analysis is a much more demanding task. This type of analysis is often used to study the low frequency response of moored systems to 2nd order wave drift loading, and to wind loading. The normal solution method is quite different from that used by OrcaFlex’s wave frequency solver. We have developed a method of re-expressing the low frequency problem in a way that can be handled by the same underlying frequency domain solver code.
Using the same underlying solver code for both wave frequency and low frequency means that all result types and variables currently supported in the wave frequency solver are also available in the low frequency solver. Mooring line damping is linearised by the same frame invariant MMSE scheme employed at wave frequency. And finally, a less obvious but very important benefit of sharing the same solver is that any future development will be quicker and less prone to error.
These enhancements now mean that OrcaFlex has a frequency domain engine capable of performing mooring analysis in the frequency domain. However, this should really be considered a work in progress. While the solver is very capable, there are further enhancements that would make it easier to use:
We feel that we have made a good start towards making OrcaFlex an effective tool for frequency domain mooring analysis and now have a powerful solver which we can build on and improve. We would really appreciate and encourage feedback to help guide us in making the next steps towards that goal. So, if you have interests in this area, we would love to hear from you and learn how you feel the program could be improved.
In recent releases we have added a number of features to make modelling of connections more flexible:
One notable limitation in all of this, is the ability to have connections at mid-line nodes. The nodes at each end of a line can be connected as slaves of other objects. But the other nodes in a line are always master of their degrees of freedom. Other objects can be connected as slaves of mid-line nodes, but mid-line nodes could not previously be masters.
That has changed with 10.1, very much driven by the desire to apply constraints to mid-line nodes. It is now possible to define mid-line connections, that is to specify that nodes away from the ends are slaves of other objects. By making a mid-line node slave to a constraint, we are able to constrain individual node DOFs. Imposed displacement constraints can be used to impose the motion of a mid-line node. Mid-line nodes can, of course, be connected to objects other than constraints. End nodes can be connected as slaves to constraints, thus allowing the same capabilities.
As a fun demonstration, the animation below shows a single line with the node at the mid-point connected to a constraint object. The constraint object introduces a single translational degree of freedom. The simulation was started with the mid-point node initially perturbed and then released at the start of dynamics. The resulting motion is, in essence, just like the pendulum above.
Obviously this is not intended to be an example of real-world OrcaFlex modelling, but it hopefully serves to illustrate the point. Without mid-line connections this model would have required two separate line objects, joined together at the constraint. Modelled with mid-line connections, a single line can be used, and more importantly, a single range graph plot can show the results for the entire line.
Way back in version 9.2 (released in 2008) the OrcaFlex batch functionality was extended to make use of all the processors on a machine. Before then jobs were processed in serial fashion. This was an excellent development, but as is so often the case, changes in computer hardware soon caught up with us. Machines with larger numbers of processors became available, and such machines come with complications:
In version 10.1, we have made changes to support machines with more than 64 processors, and to be aware of NUMA. As a result, OrcaFlex batch processing now scales much better on such machines.
The same issues affect Distributed OrcaFlex. Consequently, we are making similar changes to Distributed OrcaFlex and plan to release an updated version later this year.
The solution that we are opting for with Distributed OrcaFlex is to use multiple processes rather than multi-threading as used by OrcaFlex batch processing. One consequence of using multiple processes is much better scaling for Python external functions and post-calculation actions. So if you integrate Python code in that way you might find that the new Distributed OrcaFlex implementation is useful – even if you only want to process jobs on a single machine.
So, that’s OrcaFlex 10.1. We hope you enjoy it, and find good use for all the new features. We are already busy working on 10.2 which you can expect to see towards the end of 2017.
The Python interface to OrcaFlex was introduced in 2008 alongside version 9.2 and has been steadily growing in popularity. The Python interface exposes the functionality of OrcaFlex to the Python programming language. The ability to automate OrcaFlex this way is extremely powerful.
However, writing programs to automate OrcaFlex can be a daunting task, especially to many OrcaFlex users who typically are not experienced programmers. The documentation for the Python interface is a useful reference once you know your way around, but does not provide a simple introduction for beginners. This year we have attempted to address that concern by developing and running Python workshops, which have proved to be very popular.
In order that as many of our users as possible can benefit from these workshops, we are making available the primary document produced for the workshops. This is a high level overview and introduction to the Python interface that attempts to fill in some of the gaps not covered by the reference documentation. This introduction document can be downloaded from our documentation page. As well as the document, all Python source files from the document are included as a convenience.
We hope that this improvement to our documentation will make the Python interface more accessible. If any of our users have further suggestions for improvement, we welcome them.
In a recent paper (Impact of Bathymetry on the Mooring Design of an Offshore Floating Unit, OMAE2016-54965), DNV GL authors Jaiswal, Vishnubholta, Cole, Gordon and Sharma examine the effect of using an accurate seabed bathymetry on typical mooring results. Their motivation was to understand potential limitations in the assumption made by most mooring software that slope of the seabed is constant along the direction of each mooring line.
To explore this they consider the case of a hypothetical 8-legged all-chain-moored semi-submersible, located over a simple escarpment (with a constant profile). Consequently the water depth at the anchors varied between c150m and c250m. They considered two different seabed representations: (1) the accurate bathymetry, and (2) an approach equivalent to the constant slope assumption in most mooring software.
OrcaFlex is used for static (including wind, wave & current) and coupled dynamic time domain analysis. For 1st order dynamics waves are included. For 2nd order dynamics, wind and waves are included.
Results for line pre-tensions and the min and max values of vessel offset and line tensions are compared for each seabed representation. They conclude that there are “significant differences” in vessel offset and maximum mooring line tension when using different seabed representations. The authors point out that these results can’t be generalised, but further conclude that where there is uneven seabed bathymetry and marginal safety factors, it may be advisable to use a more accurate bathymetry.
As an aside to the paper summary, please note that we are actively enhancing OrcaFlex functionality for traditional mooring analysis. Wave Frequency Frequency Domain was added in v10.0 (Oct-15), and we’re currently working on a Low Frequency Frequency Domain solver – this should be forthcoming in OrcaFlex v10.1 (cOct-16), unless any last minute hitches postpone it to 10.2.
You can download the paper from the ASME paper here.
The next OMAE conference is to be held in Trondheim, Norway, in June 2017. Orcina are planning to attend and we look forward to seeing you there.
Once again, it’s the time of year when we issue a new release of OrcaFlex. This year, for the first time since 2006, sees an increment to the major version number! We are delighted to announce the 2015 release of OrcaFlex, version 10.0.
The software was finalised and built on 20th October. We are currently preparing the installation program, and will then dispatch the software. All clients with up-to-date MUS contracts should receive the new version early in November.
Version 10.0 introduces much new functionality, including:
These are the most significant developments. As always there are a great many more enhancements which are documented in the What’s New topic for 10.0.
We are very pleased to announce the 2014 major release of OrcaFlex, version 9.8. The software was finalised and built on 28th October. The next step is for us to prepare the installation program, and then dispatch the software. All clients with up-to-date MUS contracts should receive the new version early in November.
Version 9.8 introduces a variety of new functionality, including:
These are the most significant developments. As always there are a great many more enhancements which are documented in the What’s New topic for 9.8.
What follows is a brief introduction to each of the new features that we consider to be of most significance.
The major new development in version 9.8 is known as Supports. It is yet another contact model. The feature has been quite some time in the making and was developed originally to meet the needs of pipelay modelling, specifically S-lay. The new functionality is a contact model that has been designed to enable efficient modelling of pipelay rollers. However, this contact model can be used to model more than just pipelay rollers which is why we have chosen a rather non-specific name for the feature.
It has long been possible to model S-lay with OrcaFlex, although it has never been convenient to do so. The main headache was always the modelling of the contact between lay pipe and supporting rollers. Over the years we, and our users, have come up with many different ways to model the contact, none of which has been particularly satisfactory. So the prime motivation for the new development was to make the modelling of this contact more efficient and more robust, and to make the model building simpler.
Model building is performed in two distinct steps. Firstly support types are defined. These specify the geometry and stiffness of a support. A support is composed of one or more cylinders. For instance, a V shaped support is defined like this:
As shown in the above screenshot, a number of geometry options are available. The Flat, V shaped and U shaped options are intended to make it easy to model common S-lay roller types, and the User specified option gives you extra generality to model more complex or unusual geometries.
The second modelling step is to specify where the supports are located in the model. Supports are rigidly attached either to Vessels or 6D Buoys. Two methods to specify the geometry of the supports arrangement are provided:
For example, the data specification for the explicit geometry specification looks like this:
Note that the supports are specified relative to a coordinate system that, in turn, is specified relative to the vessel’s own coordinate system. This may, initially, seem unduly complex. However, the additional complexity allows you to move and rotate groups of supports. The exemplar for this is a model containing some supports attached to the deck, and other supports attached to the stinger. By defining separate deck and stinger coordinate systems we are able to, for instance, rotate the stinger about its hinge without moving the on deck supports.
The resulting model appears can be seen in the 3D View screenshot below:
This is quite a simple model of a rigid stinger. Much more complex models can be built with ease. As mentioned above, supports can be connected to 6D Buoys as well as to Vessels. This allows us to create roller boxes that can pivot, hinged stingers, articulated stingers, and so on. The next screenshot is of a rigid hinged stinger, and is taken from our newly updated example suite.
As well allowing for much simpler model building, the new supports contact model brings other benefits. Most importantly the new contact model is very robust. Each contact cylinder has a preferred side, i.e. above the support rather than below it. This leads to very reliable and efficient statics convergence, with no need for “helper” objects to guide the line to the preferred side of the support.
The supports contact model is based on the same underlying algorithm as the line contact model. The supported lines are splined and this means that the contact point can move smoothly in the axial directions of the supported lines during dynamics. Unlike some line contact modelling scenarios, there is no requirement for torsion to be modelled in the supported lines. This means that convergence in statics is, as a general rule, quick and reliable.
The new supports functionality complements the existing capabilities of the program that are applicable to S-lay. For instance the pipelay code checks functionality, the ability to model pipe-in-pipe and piggbyback pipes, etc.
As mentioned above, the new supports feature can be used for applications other than S-lay. The key aspect of the feature that sets it apart from the other contact models in the program is the concept of a preferred side for the supported lines. This can remove the need for “helper” objects and so greatly simplify the model building and make convergence more robust. In our 2014 season of User Group Meetings we present a number of models that benefit from the new supports contact model.
The video below shows a mid-water arch model with the guttering built using U-shaped supports. The model is quick and easy to build, and the convergence in statics is very robust. The video shows OrcaFlex performing the static analysis and shows how quick the analysis is.
The next video demonstrates a half-moon lift. Before the existence of the supports contact model, statics convergence would have presented quite a challenge. The preferred side feature of the supports contact model means that statics convergence is simple. Again, the video captures OrcaFlex performing the analysis and again it is very quick. Blink and you may miss it!
We are confident that there are many more applications that will benefit from the new supports contact model and look forward to learning from our users as they explore the new capability.
We at Orcina are all very excited by the possibilities opened up by this new feature. We hope that you the users will find the new functionality to be as useful as we believe it to be.
In version 9.5 we added slam force modelling for 6D Buoys. This modelling was based on the user providing slam coefficients for water entry and water exit, Cs and Ce. These coefficients were constant. As an alternative to constant coefficients, water entry and water exit forces on 6D Buoys can now be calculated using variable slam force data that varies with submergence.
The variable slam data model follows the rate of change of added mass formulation given in DNV Recommended Practice (RP-H103, RP-C205) and it allows slamming and water exit forces to be modelled for buoys that are fully submerged but near the surface, as well as for surface-piercing buoys.
In addition to allowing slamming and and water exit forces to be variable with submergence, the program now allows 6D Buoy added mass coefficients that vary with submergence.
The new development is intended to make it possible to model water entry and exit loading more accurately. In the future we intend to allow the same hydrodynamic loading models to be applied to line objects.
A critical aspect of any simulation tool like OrcaFlex is its runtime efficiency. That is, how long it takes to perform simulations. Whilst we think that OrcaFlex is already very efficient, we are always on the lookout for ways to make it even faster.
One area where there has been potential for improvement, at least in terms of efficiency, is in the calculation of wave loads for irregular seas. An irregular sea in OrcaFlex is modelled as a linear superposition of linear components. Evaluating wave kinematics (particle velocity and acceleration) involves expensive trigonometric and hyperbolic operations. Since these operations are performed for each wave component, models with large numbers of wave components can take a long time to run.
In previous versions of OrcaFlex, the wave kinematics were evaluated exactly. The kinematics were computed for each rigid body (e.g. node or buoy), at every time step. For a model whose calculation is dominated by the nodes – the usual case – a general rule of thumb is that when there are 200 wave components, half of the computational effort is spent evaluating wave kinematics. When there are 400 wave components, 2/3 of the computational effort is spent evaluating wave components, and so on. So, there is clearly an opportunity to improve efficiency if suitably accurate optimisations can be found, and version 9.8 introduces some such optimisations. The extent to which these optimisations give efficiency gains varies from model to model.
The strength of wave kinematics decays with depth. In very deep water, it is quite possible that the majority of nodes in a model experience negligible loading due to waves. Version 9.8 now allows you to specify a cutoff depth below which wave kinematics are not calculated and are taken to be zero. For deep water cases this is the simplest and most effective way to increase efficiency.
The new version allows you to specify a time interval for wave kinematics calculations. This allows you to decouple the update frequency for wave kinematics calculations from the time integration time step. For instance, there may be structural reasons for using a short integration time step, but the wave loading varies more slowly. The program uses linear interpolation to calculate wave kinematics for time integration time steps that fall in between the wave calculation update steps.
One huge opportunity for optimisation is to evaluate the wave kinematics at fixed points in space. So long as we always evaluate the wave kinematics at fixed points, we we are able to use standard trigonometric identities to replace expensive trigonometric operations with simple multiplication and addition operations. Version 9.8 offers a couple of ways to take advantage.
One option is simply to neglect the motion of the nodes during the simulation. The kinematics are calculated assuming each node remains at its static position. This assumption could be reasonable for lines attached to fixed structures, or for low wave height bins in a fatigue analysis.
For models where using the static position is not tenable, the program offers an alternative. Instead of evaluating the wave kinematics at the instantaneous position of each node, the wave kinematics are evaluated on a spatial grid, whose spacing is determined by the user. Then, the wave kinematics for each node are calculated by linear interpolation over the grid. The program uses a grid of infinite extent, but only calculates kinematics at the grid points as needed. This adaptive approach allows the the program to be flexible and yet retain efficiency.
Although the efficiency gains offered by these new developments are enticing, you must always take great care that you don’t sacrifice accuracy for the sake of reduced simulation run time. It is always advisable to perform some sensitivity studies to demonstrate that the approximations used do not unduly influence the results of interest.
.
Since releasing the line contact feature two years ago, we have become aware of a very specific modelling issue when the line contact penetrators and the spline have the same, or very similar, diameters. An example of this is a centralised pipe, where the centralisers are in an interference fit with the outer pipe.
The program calculates penetration for line contact by calculating the closest approach of the penetrator to the splined line, and then accounting for the contact diameters of the two lines. The reaction force is applied in the direction defined by the line that passes through the two points of closest approach. Consider the case represented by the following diagram:
The blue line is inside the black line, and the contact diameters are quite different. When the inside line’s contact surface is just touching the outer line’s contact surface, the two centres are far apart and the direction of the line between these centre points is well-defined.
Now consider a case where the contact diameters are very similar.
When the two lines are in contact, their centres are almost on top of each other. The direction is defined, but small perturbations in position of either line lead to large changes in direction. When the centres are exactly coincident this direction is ill-defined and the contact force model is singular.
In the case where the penetrating line and splined line have the same diameter, the singularity in the force model can lead to noisy or unstable simulations. Even if the diameters are close but not exactly the same, the force model is near-singular which can cause instability.
A new feature, penetrator discretisation, has been introduced to tackle this issue. By discretising the original penetrator into multiple smaller penetrators, placed around the original contact surface, the contact can be modelled without singularity.
The new functionality asks the user to specify how many discretised penetrators are to be used, and their scale relative to the undiscretised penetrator. The discretised penetrators are then evenly distributed.
This is most easily described pictorially: the below figure illustrates an original undiscretised penetrator, drawn in black, from a penetrating line that is in an inside relationship. This penetrator has been discretised into multiple penetrators, drawn in blue, using a discretisation count of 3 and a discretisation scale of 0.4.
The centres of the blue inner lines are far away from the centre of the black outer lines and so singularity is avoided.
Discretisation is also possible – and useful – for around penetrators. This is illustrated below using a discretisation count of 3 and a discretisation scale of 1.6.
When modelling interference fits using line contact, the deficiencies of the undiscretised model are often very significant. The improvement to robustness and stability resulting from penetrator discretisation can be profound.
In the previous releases of OrcaFlex, splined lines for line contact required torsion to be included. Whilst torsion is modelled perfectly well by OrcaFlex, there are a couple of consequences:
One of the by-products of the line supports development is that we were able to relax the restrictions for splined lines to require torsion. So, for splined lines in line contact relationships that do not model friction, modelling of torsion is no longer required.
Models that are able to take advantage of this and exclude torsion modelling should see much improved statics convergence.
One of the major development tasks that we have been working on recently has been a re-implementation of our low level solver. This has been motivated by the desire to be able to:
OrcaFlex 9.8 now uses the new solver, but we have not yet been able to realise any of the above goals! So, functionally this change brings few immediate benefits. Rather we are laying foundations for the future.
The exception to that statement is that the new solver allows us to remove the restriction that 3DOF vessel calculated primary motion was not available for the implicit solver. For version 9.8 this restriction has been removed. So, let this minor enhancement be a taster for the much more significant improvements that are to come!
So, that’s all folks, as the saying goes. We hope that you enjoy and appreciate this new version of OrcaFlex, and find good use for all the new features.
