I saw this 'wishlist' idea at another forum and found it a good idea. Feel free to add your wishes too!

For a dynamic (harmonic) response calculation add the following features:

1 - add option to calculate forced response for all calculated natural frequencies automatically instead of specifying the frequencies by hand(the user now has to adjust the load case definition each time the model is changed with new natural frequencies as a result).

2 - add option to calculate the response of a harmonic force spectrum. Currently one can only calculate the response of ALL forces on ALL natural frequencies. Normally one would like to see the response only for those natural frequencies which are within a certain range of the excitation force. For instance, say a force time signal consists of mainly a 1st, 2nd and 4th harmonic. Assume a band of +/-20% accuracy and 1st harmonic is 6 Hz. If there are natural frequencies at 5, 10, 12, 17, 23 Hz then I would want a response at 5 Hz with force from 6 Hz (1st harm), at 10 and 12 Hz with force from 12 Hz (2nd harm), etc.

3 - add 'vibration velocities' to the report function. For a dynamic response (harmonic forces) it is common to deal with velocities and not with displacements since velocities can be judged against one single allowable level (usually 40 or 80 mm/s pp). Since displacements and frequencies are already avaliable it would be very simple to add a velocity report (v = 2*PI*f*d). At this moment I have to calculate each single displacement value to a corresponding velocity by hand...

4 - add a plot function which shows the undeformed AND the deformed model due to the excitation force, plus a vector showing the highest vibration velocity (mm/s) at the corresponding location in the model (and the natural frequency added in the title). Then you will have one single output page for a problem situation and don't have to deal with many report pages instead.

In "List" mode, under "Elements", some data values are shown RED. I think the RED font data is data that has been modified, or manually changed from the initial data that is in "carry forward" mode. Often it is an advantage to see where the data was changed. The location of the change in data can represent an intentional change in an operating condition, such as temperature or pressure change at a control valve. In such cases the data then "carries forward" until the data value is changed in a subsequent element.

Sometimes, however, a change to the element data is inadvertent, and is subseqently corrected. Or when copying models, the operating scenarios are different and the location where the temperature or pressure changes in the model needs to be revised. In such cases, it would be helpful, in my experience, to "restore" the element data to "carry forward" mode, so that the pressure or temperature, for example, would continue to carry forward uninterrupted until the next purposeful change in the data.

In large models, I have found it takes considerable time to sort through P & T data to change "RED" data throughout the model that was "locked" as a change to the "carry forward" mode. So, my "wish" is for a "restore" button that would restore the carry forward mode to the specific element data that is selected.

Good idea Jan,

Can I suggest for the purposes of those that have unavoidably large models, ways and methods to ensure that CAESAR II doesn't crash and that a solution can be reached without upgrading the computer.

I found that a changes made to a large model result in increased page file use (as I understand it, i'm no expert in this area of computers) and that there is no memory dumping i.e. everything accumulates so that small changes result in vastly increased use of memory - resulting in a frustrating crash and restart of CAESAR II which consumes another 10 minutes.

Not sure I explained that too well but the solutions I came to were:

a) adding more RAM, not ideal but not expensive either (i haven't had these issues with CAESAR II before I had this monster of a model)

b) using the link piping input utility. - more could be said in the help file to aid peoples use. i.e. I messed around with C nodes when a simple statement in the help file such as: Node 'X' in file A will correspond to the same Node 'X' in file B. Global co-ordinates really don't matter if you have correct Node numbering and it's back to KISS.
Clearly I was using the No read option to stop CAESAR II crashing.

c) is it possible to increase the number of files you can add with this utility? I found it very useful for this situation but I may use it with small(er) models for convenience, ideally I could have done with upto 20 file links. Or a way of using the same file in various areas of the model so as to not repeat 'adding' with different Node increments/rotations.

Well that ended up being a bit longer than I thought but hope my point can be understood.

For the structural modeller:

1 - EDIM command allows to set up a series of elements with a single command. You specify begin node, delta length and number of sections. But in this way you cannot control the end node number. And the user has to calculate the section lengths himself. Better way would have been to specify TOTAL LENGTH of the complete section (which also makes more sense) and the NUMBER OF SECTIONS. The section length can then be computed. Note: node numbering is important in modelling because it can make models easier to understand. If I have a series of separate beams I still prefer to use equivalent node numbers (like 1000-1040, 2000-2040, 3000-3040 etc).

2 - SECID command makes use of a library of elements. You select one from that library, OR you can specify your own values for the section properties. If you first input custom values (by using the name 'user') and then change to an element from the library, the values related to the 'user' value are still displayed (although grey), which is very confusing. It would be nicer to have the 'user' input possibility as part of the library (so: I-Beams, Channels, Tees, Angles and 'User'). And subsequently, if you select an element from the library the properties fields should be filled in for that element (now they are empty).

For both structural and piping modeller:

1 - change symbol for ANC into an XYZ restraint symbol with a different color. Now ANC restraints loke like some piece of material instead of a symbol. The symbol for XYZ restraint much better indicates it's meaning and could also be used for an anchor node. To tell the difference normal restraints could stay green arrows and anchor nodes could get red arrows in XYZ.

We will look at these suggestions.

1) Personally though, I would use the "Node" and "Element" method to generate the model. I feel you have more control over what is going on.

2) Yes we should make this more "obvious".

3) We've been discussing the "anchor symbol" for over 20 years now. It has to work 2D, 3D, in single line, wire frame, and rendered views. This topic is still under discussion.

> We will look at these suggestions.
That's a good thing! I always like the idea of developers listening to users, though often it is hard to satisfy everybody (and budget is limited too).

I hope people don't mind that I am just 'dumping' my personal user requests here. I run into many situations that might be improved so that engineer's life will get simpler. Here's another one from this morning:

1 - NODE RENUMBER: add feature to change the node number (in a simple way). I know there is some hidden function through the LIST->BLOCK OPERATIONS->NODES->INCREMENT/RENUMBER, but so often I just want to change one of the node numbers so that I can insert one in between.

2 - NODE CONTEXT MENU: change the RIGHT-CLICK menu structure such that you get direct access to node related functions like 'Change Node Number', 'Show/Modify Node Params', 'Measure distance' etc... Currently right-clicking on a node in the 3D model (it highlights then) leads to several functions that relate to displaying/viewing. That menu could be retained when NO SELECTION was made.

- allow 'included' structural files to be used multiple times. Use a node offset for the included file to make them unique in the main piping model. This feature is usefull when you have a large number of identical support structures that you want to model once and use it at different locations in the piping model. Currently you have to model each structural file separately, even if they are 100% identical.

The intent wasnt' to hide this function. It is part of the LIST, so the context menu is only there when the LIST is active. Alternatively you can use the toolbar button (which by default is in the right-hand frame of the window) to renumber a group of elements.

If all you want to do is insert a node, you could use the "Element Break" command and simply insert a single node. This works best if your node numbering increment is 5 or 10 (or more). The node numbers don't have to be in sequence, but it does make more sense that way.

If you really have to renumber a (single) node, I think the fastest way is to just change that node number on the (typically) two affected spreadsheets. Of course if that node is a tee node there is the third spreadsheet to find, and you have to account for any restraints, forces, or displacements that referenced that node. Typically though, it is just two spreadsheets and two values to deal with.



This is actually a nice idea. What other options would you want on this "context menu"?




Yes that would be a good idea. It works the way it does now because I assumed you would use the "generation abilities" of the structural modeler to completely define all structural elements - thereby obviating the need to include the structural model more than once. Hindsight is always 20/20, and now I realize this was not the best way to set things up.


]

That's one of the biggest challenges for software development! First to build in the features, then to make these easy to use (always the hardest part). And I can speak about it as a software developer.


This comes into my mind (Context Menu when a node is selected):
- When implementing the Context Menu with the Distance feature as well it would be handy if the first node is automatically set to the selected node number.
- "Zoom to node" (this is already part of the Find function but would be usefull to have here as well)