Archie_M_notes

More on thrust issues

I have been looking further the complexity of thrusts in high rise bridges. If the thrust runs out of the arch in such a direction that it gets to be a modest distance above the segment concerned, and if that segment receives a large proportion of horizontal soil pressure, there will be problems with the thrust.

Clic on the images to magnify.

 

If this arch is given backing to the level where the vertical through the springing cuts the extrados, the thrust looks much more normal.

Here there is a very slight down-turn instead of a severe upturn.

this is all part of the issue of the thrust making no sense once it is outside the domain of the forces concerned. The forces are actually all associated with the arch segment and not with the soil segment (the arch feels soil pressure but does not know where it comes from). Once the thrust escapes the arch, we are dealing with a large block of material in which the divisins have a large effect on the flow of force. It only makles sense to look at the forces as a whole. Indeed, the interesting question is where does the force leave the arch/fill block. That raises questions of what is force and what is reaction. Where there is backing, as above, we can legitimately remove the horizontal soil pressure from the arch and instead apply it to the backing. We should then treat the whole mass from the point where the thrust leaves the arch as an single entity and work out whether the resultant force is guided into the abutment.

There must be more to come from this.

Bill

Thrust line issues

I have been exercised for some time about the issue of limitations on the powerful technique of thrust lines (or, in our case, zones of thrust) as tools for visualising force flow. One major issue is the question of what bit of force gets included at which stage of the thrust line. If the structure is relatively narrow (like an arch rib) and the thrust is contained within it, there is no particular problem. In a large blocky structure or where the thrust wanders into the backing on an arch, things get more interesting as this picture (and some explanation) shows.

First a picture of the traditional thrust line for Bargower with an HB load. This has been editted down to the bare essentials.

Now look what happens if we work out where the thrust leaves the fill part associated with the segment.

The upturned end looks very strange but is actually the same thrust shown above.

The picture below shows a bit more detail of what is happening at the end there.

The grey portion of the arch shows the last segment and the fill it is assumed to support. The yellow bit of thrust line is the related section of thrust calculated on the assumption that the action of the forces can be assumed to take place between the boundaries of the arch segment projected outwards. It seems that this is unsatisfactory because the effect of the forces on the thrust line is entirely separated from the area within which the forces are generated.

An alternative approach would be to work out where the thrust leaves the domain of the loads concerned. ie where it leaves the grey area. This occurs at the point where the last section of thrust projected backwards cuts the vertical division in the fill. That is an easy calculation but produces an unexpected result which can be seen in the red piece of thrust zone. The thrust moves rapidly upwards as it approaches the end of the arch.

This effect is created by the hockey stick shape of the grey zone. the blob at the bottom creates an anticlockwise moment that throws the thrust upwards. The calculation is correct but the division of the structure turns out to be unreasonable.

Actually, the point at which the thrust leaves the structure is sensible. It is the route it takes to get there that doesn't make sense.


We are working on this. Those few of you who have version 2.4 will note these strange upturns on arches which approach the vertical at the end. In previous versions the thrust has been allowed to continue out of the arch but this also has draw backs for the overall image produced

A new decade. Where are we?

I seem to have been very quiet over recent months. That is not because I have been ignoring Archie but rather because we have been tied up with endless niggles.

Most of you will know that we have been trying to get version 2.3 out for nearly 2 years. The biggest hangup has been trying to get it stable under Vista. To do that we had to buy a new version of microsoft C++ which was so different from the previous version it would not initially load the program. Eventually we got all that sorted out and by early November we were ready to wrap it in the security blanket and send it out.

Then it transpired that Aladdin had abandoned the old HASP4s that we were using and wanted us to buy new hasps for all our customers. that provided enough of a drive for us to change our protection system to a software only one.

Of course, that didn't go entirely smoothly, but just before Christmas we sent out one new version to a customer and the installation worked as planned.

Of course, throughout all this we have been making updates to the program. Some of the changes are quite small but should make a biggish difference to operation. For one thing we have changed the load files to include a vehicle width as well as a track width. This means that Archie can check that the vehicle can fit on the prescribed "Lane width" which we have now renamed Bridge Width. There should be no more cases of people applying a 3.5m wide HB load to a 2.5m wide default lane.

We have also changed the way the thrust position is calculated so that the thrust never extends beyond the sphere of the loads it is supporting. This will prevent the apparent error of thrust crossing and coming out of the next arch in a viaduct.

There are a number of other changes in hand and we hope also tohave a brand new web site up and running in the very near future.

Happy new year to you all.

Oh, and by the way, I think that 2010 marks 25 years since I first made a little program called CIRAR (in those days a file name was limited to 8 characters and it only dealt with CIRcular ARches). It was written in GW basic and was very slow but today's users of Archie-M would still recognise the thrust line output even if it is in coloured lines against a black screen.

Anyway, 25 years is a long time. Even the 10 years of Archie-M has seen some changes in my life. When we began writing it in 1999 we were told it was a wasted investment as "the arch work is al but finished".

This past couple of weeks I have been working on the design of a Flexi-Arch bridge for Macrete. So not just not finished but actually a broadening application.

Looking forward to another decade working with the friends I have made in the business.

Bill

Archie-M seminars

I have been doing seminars on arches since about 1987. For many years we called them user group meetings but it then became clear that people didn't come because they thought it was not for them. Most of those attending were return visitors.

We charge for the seminars because we need to cover the cost (typically about £1000 a time) of travel and hotel, the seminar room equipment and catering. The current charge of £100 makes a cheap day of CPD. The format is always the same. Each year I find some new aspects of arches to talk about, though it is necessary to ensure that the talks are pitched at a level that can be understood by newcomers. We gather about 9.30 and start the seminar about 10. We have a coffee break about 11.30, lunch about 1300 and serve tea and prepare to depart about 1530. By that time, everyone is often getting quite tired anyway.

During that time we usually have two lectures about aspects of arches, usually driven by my consulting work. We then talk a bit about what is new in Archie-M and what we are planning. That leads in to a more general question and answer session.

A hidden benefit is that we have a room full of people who all work on arches in some way. Some are begineers but some have been with Archie from the start. The collective knowledge base is huge.

Each year, I run the same seminar in 5 or 6 locations. This year, so far, we have done York, Birmingham, Belfast and Glasgow (just back from there). I will squeeze in a trip to London, probably in January. If anyone wants to propose a location, please let me know. If your company wishes to host a meeting then we do not charge for your staff to attend.

Are we nearly there yet?

Making Vista Programs is not as easy as it should be. The familiar cry from children in the back of a car has become commonplace in the OBVIS offices.

I think that the files on these link should be robust (If you onlu have older versions of winzip or are using the windows handler please find the zip file here. If you have the latest WinZip you can find a zipx file here). Unlike our earlier Demo's, this one is fully functional for 30 days and can then be registered if required.

If you have any trouble with this please email bill@obvis.com and tell me what the problem is.

Bill

Reaching towards Vista

As always happens when Microsoft introduces a new OS they change lots of things in a largely undocumented way. Just before Vista came on line we had version 2.3 ready to go. Under Vista it produced crashes which have given us several years of grief. At last we have 2.3 apparently stable and under a bit of stress testing. I hope we can get it out in the next month and then start to move forward with version 3 and some really tangible improvement in function.

Bill

Crown levels are critical

I am constantly surprised at the use of wrong data in Archie-M. I recently had dealings with a viaduct with semi-circular spans. The rise of each span was recorded as different by up to 250mm. A careful check (with a total station) revealed that the error was in picking the springing level and all the crowns were at the same height. This made a substantial difference to the multi span capacity.

Time to say again. Stand back and look first. If the dimensions disagee wtih what you think you saw check the dimensions before you change your view.

If the spans measure differently, don't start analysisng but look for reasons for the spans to have changed.

A new Demo Pack

Version 2.3.1 has been a long time in the development but we think it is ready for use now. We will circulate it to users as soon as we have finished testing. In the mean time, the Demo can be downloaded from.
Download Archie_demo_pack.zip (1607.6K)

Bill

Extracting Live load Thrust

I was asked at a seminar last week how to extract the live load thrust from Archie Output.
A spreadsheet to do it is here.
This is a 4 page spreadsheet. The first contains the tabular output from a dead load only case. The second has the live load case. The third does the computation and the fourth the plotting. If you want to just use this sheet you will need to make sure you have the right number of segments (60 in this case).

Bill

Complex loadings

When we first began with Archie back in 1984, lots of things were much easier. All our users worked on roads and road vehicles were pretty consistent. The rules for distribution meant that we could deal with full axle loads and distribute them over a width of 3.3m plus the depth of fill but limited to the width physically available. We called that the lane width and put in a default value of 2.5m as this is near enough the physical width of the vehicle.

Then came railway work and lots of things changed. The transverse distribution rules are different, not least because the railways don't allow the smoothing out of centrifugal effects etc. Also, the railway patch loads are rather different, under the sleeper they are 800mm wide and 250 front to back instead of 300 square.

We have made a number of modest changes to accommodate  these differences, but they require  a degree of  involvement from the user. For example, on railways we suggest using wheel loads and a lane width of 1.5m minimum. The "axle" for the wheel load needs to be 500mm long and the 300mm patch each end increases that to 800.

HB vehicles need a bit of thought too because they are 3.5m wide, so wont fit on the default 2.5m lane (what happens if you don't change it is that the load goes on the 2.5m width anyway).

So we made some more changes. In version 2.3 of Archie-M we changed the title "Lane Width" to B
"bridge Width". It is still a bit confusing, so if you can think of a better short title we would be pleased.

In the load file we now include a track width (between wheel centres on an axle) and a minimum lane width. The program now checks and wont attempt to put a load on a bridge that isn't wide enough.

Finally we get the SV vehicles which are very wide. The wheels are 2.65m apart on the axles so at 1.5+h effective width, h has to be 1.15m before these patches overlap. The model loads (which were created by a user) deal with wheels rather than axles and the track width is set to 0.1m to mimic the wheel patch. In version 2.3 it will be necessary to think about an appropriate bridge width and minimum lane width. Ideally, the minimum lane for the wheel would be 3m wide. ie symmetrical about the wheel and generating no overlap. If the bridge is narrow, or the load might get close to one edge, it may be necessary to reduce these values to account for the unavasilability of the symmetrical load path.

Life gets really complicated with the SV TT vehicle which includes the tractor and a trailer with 4 wheels per axle. There is no simple model for this case. It may even be necessary to deal with it by combining the two wheel loads in each half of an axle. Thus, with a 3.7m wide vehicle, one might have a lane width of 1.85m and track width of 0.1m where there are two wheels per axle and 0.96 where there are 4.

By the time we get to version 3, which might still be a year away, we hope to be able to deal with explicit load patterns and a sensible distribution model.

In the mean time, if you have a complex case, I have tools that might help

Bill