Here's a minor item to put on the wish list for 4.60. I like the new reducer element for 4.50. Even though it has no meaning for B31.3 piping, it certainly looks better and will give a consistent method of coding for all analysts.

Now, this would pretty much be a graphical deal only. Would it be possible to modify the reducer element and create a pipe cap element? It wouldn't matter from a purely stress analysis point of view, but it would make for a cleaner and more robust visual presentation of a piping system and allow for a representation of a head on a vessel cylinder model instead of a big open cylinder.

I know Caear isn't a 3D pipe modeling program like CADWorx and such, but the new graphics engine certainly looks to be moving in the direction of producing more presentation quality graphics for clients, reports, etc. Adding a grpahical element like this would be a logical step toward that end.

"Wish List" item noted.

Like Mr Klein I have also been evaluating the latest verison of CAESAR II and have a list of wishes I would like to see added to CAESAR II.

It is good to see a reducer added to CAESAR II however it would be nice since CAESAR II asks for the reducer diameter and wall thickness to see these values changed by default in the next element rather than having to redefine these.

I have noticed that as I insert new rows in the static load case editor I now have the option to renumber the load cases which is very nice, however when I wish to delete a row I do not have the same option, and hence manually have to change the row number references again.

Actually that is how we planned it to work. When you specify the 2^nd diameter and thickness, these values are used to set the diameter and thickness on the next new element. Note, this only works when generating a new element after a reducer. If you return to a reducer element somewhere in the middle of the model, and change the values for the 2^nd diameter and thickness, the diameter and thickness values on the following spreadsheet will not be updated. We felt it would be a bad idea to change data on a spreadsheet not currently visible.

At the moment, I don't think this is possible, because of the ramifications encountered when dealing with combination cases. For example, lets say you want to delete load case #9. Ok fine, we could eliminate that and renumber everything below it. But, what if case #15 was "L9+L6", and later case #22 was "L15+L19"? Obviously I made these case numbers up, but you should see the problem. Do we automatically delete all cases built from the one you deleted? (If you answer "yes" to this, then my next question is "what do you expect the program to do, after everything has been deleted and renumbered, and then you realize that you deleted the wrong case by accident"?)

We felt that trying to renumber load cases following a delete operation was just way to messy.

Regarding the reducer element, it would be nice to have the reducer length input as part of the data. I believe these are standardized based on the larger diameter.

Another thing I noticed, is the metric database for pipe schedules and valve and flanges seems to be incomplete. Although, I doubt this is v.4.50 specific.

Ok, I'll check this out.

I presume you're using the CADWorx database? I'll run this past the CAD group.

A seperate message box for program requests
Which would be open for the life of the Build, could be usefull.

With regards to the metric database: we always try to maintain a complete valve and flange database, but we don't have all the standards for the entire world. What (specifically) are you looking for?

With regards to the message box for program requests: it would be simpler (all around) just to send us an e-mail.

For the valve and flange database, I only want the metric equivalent of the English database. The same goes for the pipe schedules. For example, I am currently working on a job in Malaysia that uses DIN pipe sizes and Sch. 20, Sch. 40, etc. wall thickness. If I use the MM.FIL units file (and DIN Piping Size Spec.), put in 750 for diameter, and 20 for Wt/Sch, it stays 20, instead of CAESAR pulling in 12.7 mm from a database.

However, if I go create a custom units file with English.FIL as the template, and change dia. and Wt/Sch. to mm, I can put 30 for dia. and 20 for sch. and it converts to 762 mm for dia. and 12.7 mm for wall thickness. Similar results occur with valve or flanges using MM.FIL. Seems like it wouldn't be too hard to convert existing ANSI databases when using Metric units.

One other little item: would it be possible to add a "hotkey" for SW, NE & NW ISO View? It sure would be nice to hotkey those views instead of manipulating the rotate command.

The "DIN" specification doesn't have schedules, so if you activate the "DIN piping spec", schedule designation is disabled. This behavior is independent of the units file in use.

If you just want to use metric units, you can use the "ANSI piping spec" and then enter metric nominals and schedule numbers.

This is an excellent idea. I'll put it on the list.

Ok. I figured out that "metric ANSI" was what I needed.

Will "Hot Modulus" ever be activated? I don't use it often, but it would be nice to have it available when needed.

The codes that CAESAR II currently supports (except for FDBR) all state that the flexibility analysis should be performed using the cold modulus.

When we support EN-13480, the hot modulus will be activated (perhaps just for those codes that require it).

One thing that really bothers me about the new graphics is limit stops cannot be seen when viewing the model with Gouraud Shading (3D rendering). Not real sure how that should be changed. Is there a way to put the arrows indicating a limit stop at the bottom of the pipe, instead of the centerline?

Attempting to put things below, next to, or above won't work. Something else will obscure what you're looking for.

The best way to handle this situation is to turn on the "invisibility option" (the tooltip here says "translucent objects"), so you can see through the pipes. On the toolbar, this option is invoked using the button that looks like a vertical white cylinder, next to the "change display options button". By default, the degree of translucence is 50%, but this can be changed from the "display options" button by clicking on the "visibility" tab. I personally like 75 to 80 percent.

WHEN RUNNING THROUGH THE RESULTS OF A PARTICULAR ANALYSIS, IT WOULD BE VERY HANDY TO HAVE A '+/-'
SEPERATION ON THE FIND FIELD IN THE RESTRAINT SUMMARY, THIS IS OF PARTICULAR USE WHEN SEARCHING FOR +VE MOVEMENTS OF RESTS -IE +Y, OR FOR LOOKING FOR POSTITVE UPFORCES ON Y RESTRAINTS

Yes, other users have requested similar capabilities. A "minimum" function is being planned for Version 5.00.

WISH 1..
I 'WISH' Hoops would stop crashing my computer causing me to lose 15-30 mins of work every time.
To be honest, the hoops program has the ability to be a good platform and the release of 4.5 has started to realise some of the potential hoops has.
However in its current guise, i find it full of bugs, prone to crashing the computer, slow and cumbersome, and user unfrendly.
I Fail to understand why COADE has removed the
2D graphics option, as some of us operators are not using CRAY supercomputers to run Caesar.
WISH 2.
Why put the damn undo button next to the insert/advance button? Whenever i change it,
it reverts back every time.
its as sensible as putting the eject button next to 'fire' on a fighter jet.

WISH 3.
The ability to copy/amend and manipulate support entries.
IE: remove all support types for each node with one action, or add a specific restraint for a
list of nodes (ie add remove guides along a rack)
or add generic gaps to a list of nodes.

WISH 4.
The abillity to interegate the movements and stresses per selected node/support on the static hoops processer, without flipping to the reports.

WISH 5.
Consistancy between what hoops(input) shows
and hoops(static processer) shows.
SIF indicators are a prime example.

WISH 6.
Indication of support positions on the animation.

WISH 7
HOOPS Stress indication values to match those
in reports (evident if the Sh is reduced due to high temp)

I could go on, and yes i am being just a little critical of what is an excellent program.
However, i just feel that COADE have missed the ball on this release of Caeser as it could have been and has the potential to be so much better.

Regards.

SP.

1a) Saying the program crashes is of no help. The reason being is because we used the program extensively before it was released, and the beta test group also used it. What (exactly) are you doing to cause this? How are you running the program - for example, do you have the graphics and the spreadsheet open at the same time? Does the crash occur only when you click a certain button, etc?

1b) We removed the old "2D Graphics" because:

- 5 years ago users where threatening to switch to another pipe stress program if we didn't improve our graphics. We selected the HOOPS library because of the capabilities offered.

- The "2D Graphics" relied on a graphics engine we developed in Assembly Language in the late 1980's. The intelligence we wanted in the graphics could never be supported by this old engine.

- We wanted a 3rd party library to address the many hardware and operating system combinations.

- We simply couldn't add any more capability to the graphics using the old engine.

- As of the release of Version 4.20, no work has been done on the "2D Graphics". All new capabilities have been incorporated into the "3D Graphics", relying on the HOOPS engine.

1c) You don't need a super computer. The program runs just fine on my machine, which is at least six years old and started life as a Dual-300Mhz machine. Since then I've upgraded the processors to twin 700Mhz.

Yes, HOOPS starts up slower than the old "2D Graphics", but that is because the engine computes the 3D model and all possible display information before it releases control to the user. (You can rotate and zoom on the initial center-line model while the remainder of the information is being computed.) However, once this initial preparation is completed, the HOOPS graphics are infinitely faster than the old graphics. In the old graphics, every push of an arrow key (to rotate the model), or a request for information (say nodes), would require a complete redraw, which required a complete recaluation of the model. None of this happens in HOOPS, your view changes instantly since HOOPS knows where everything is.

2) If you don't like where the button is, change it. The toolbar is customizable.

3) This may be a good idea, we'll have to discuss it. How often and under what circumstance would you use this capability?

4) You can do this now. In the static output processor, enter the HOOPS graphics. Then click the [Grid] toolbar button. This will display a floating window allowing you to select load cases and reports for display in the grid. Clicking on an element in the grid highlights it in the graphics. (You couldn't do that in the old "2D Graphics".)

5) All HOOPS "input" capabilities are available in the HOOPS "output" processor. We are not finished implementing HOOPS in the "output" processor - this area will be much improved in Version 5.00. Obviously, output capabilities will not be available in the input.

6) We'll look into this idea.

7) What did you have in mind here?

I disagree, we haven't missed anything. We have been suggesting to our user base for over three years to start using the HOOPS graphics, and provide feedback on these unfinished graphics. Now that the input implementation is nearly finished, HOOPS is the only graphics engine. We couldn't "not release", due to piping code and other technical changes. If you give the new graphics a chance, (try out all the buttons) you'll find the HOOPS graphics overall faster, and more capable.