RING - Support & FAQ
Version history:
Support to users:
RING 1.5 has now been replaced by LimitState:RING 3.0, which is a fully supported commercial product. It is not possible to offer free technical support to users of RING 1.x. However, reports of bugs and constructive comments and suggestions are essential in order for the software to be improved in the future, and are most welcome. Please direct these to: m.gilbert@sheffield.ac.uk, with 'RING-COMMENTS' as the subject.
Q1. What is the 'failure load factor' ?
Q2. When I specify end abutment blocks, I
seem to get a very low predicted load factor. Why?
Q3. Is RING being constantly updated?
Q4. Has RING been validated against
full-scale test results?
Q6. How does RING deal with transverse distribution of the load through the fill?
Q9. The more bricks I specify per ring, the lower the failure load factor. Why?
Q1. What is the 'failure load factor' ?
A. For whatever live load is specified, RING will determine the multiplier, which when applied to this load, leads to collapse. This multiplier is termed the 'failure load factor'. e.g. if a 1kN single axle load is specified and RING indicates a computed failure load factor of, say, 154, this means that the load which would cause collapse is 154kN. Alternatively if a 10kN single axle load was specified in the previous case the failure load factor computed would be 15.4 (15.4x10=154kN).
Q2. When I specify end
abutment blocks, I seem to get a very low predicted load factor. Why?
A. If an end abutment is specified then often RING will predict a
sliding failure just below the skewback at the top of the abutment. In
reality when soil is present behind an abutment such a failure mode
would be resisted by horizontal soil pressures. Currently in RING the
abutment option is really meant for situations when a beam and arch
span are adjacent to one another, when the possibility of the above
failure mode is real (though it is possible in RING to manually specify
pressures acting on blocks below the skewback, this can be a laborious
exercise).
Q3. Is RING being constantly
updated?
A. Yes. At present the core of RING is being completely rewritten using
the programming language C++. RING 2.0 is scheduled to be posted later
in 2005.
Q4. Has RING been validated
against full-scale test results?
A. Yes. RING was originally developed as a means of interpreting the
results from full-scale laboratory tests, and reasonably good
correlation was found. Interested users are referred to the reference
list at the back of the RING manual.
Q5. How does a multi-span
analysis work using RING? Does it involve manually balancing thrusts
from adjacent arches, as with ArchieM?
A. RING uses rigorous optimisation techniques to find the critical
collapse load factor, which can be found when the yield, mechanism and
equilibrium conditions of plastic analysis are all simultaneously
satisfied. In ArchieM by balancing thrusts from adjacent spans the user
is basically attempting to carry out this process manually (the yield
condition being deemed to be violated when the line of thrust lies
outside the thickness of the pier).
Q6. How does RING deal with
transverse distribution of the load through the fill?
A. RING is a 2D analysis program. Hence the user must make appropriate
assumptions about the amount of transverse distribution which will
occur (unfortunately this is an area which would benefit from more
research).
Q7. I am modelling a
multi-ring brick arch bridge. I get very different answers depending on
whether I define each ring separately or simply specify an overall
barrel thickness. Why?
A. Defining each ring separately sets up a series of separate rings
which can interact with each other via interfaces which the user may
specify to be frictional. Such a configuration is usually significantly
weaker than a single barrel of thickness equal to the sum of all the
rings - hence a lower predicted capacity will result.
Q8. I am modelling a
multi-ring brick arch bridge. I am not sure if ring separation
(delamination) is present. What assumption should I make when using
RING?
A. This is a difficult question. Basically it depends on your judgement
of the strength of the bond at the joint between rings. If this is low,
or non-existent (as it certainly is in many cases) then you should
treat the barrel as a series of separate rings, interacting via
frictional interfaces. Also you should remember that the
square scaling law for stresses in gravity structures means that a
large bridge needs to have a greater inter-ring bond strength to avoid
ring separation than a geometrically similar small bridge. Remember
that the effect of your assumption on carrying capacity can be dramatic
and it will normally be prudent to experiment with differing levels of
ring separation (e.g. separating bottom ring only, or partial
separation in crown region only for example).
Q9. The more bricks I specify per ring,
the lower the failure load factor. Why?
A. Relative rotations (hinges) and sliding movements between blocks are
a necessary feature of failure mechanisms. In RING these can only occur
at the interfaces between bricks/block units. Thus the fewer units that
are specified, the less options the optimiser has open to it when
trying to find the minimum load factor. In practice when the number of
units exceeds say 40 or 50, changes in the computed load factor as a
result of adding further units will generally be small.
Future enhancements:
Feedback on the enhancement(s) you most want to see in the next version of RING are most welcome. Enhancements currently being considered are:
- Including a 'gross displacement mechanism analysis' option (this option is already available in the research version of RING and is potentially useful for dealing with soil-structure interaction problems. In such problems stabilizing horizontal soil pressures are only mobilized with large arch displacements, but conversely these gross arch displacements adversely affect carrying capacity).
- Including backing/spandrel masonry as discrete blocks (this option is already available in the research version of RING)
Copyright © 2007, CLADU, The University of Sheffield.
