Comments

• Sergio

  August 2017 edited August 2017

  I'm using constantly Mecway as a postprocessor for Calculix without problems (only has to take care of the unit as it assume that the .frd will has Newtons and meters).
  
  Surely you have a problem on the input file, my advice is that you must reduce the size of your model to have something that solve as quick as possible in order to be able to make several tries and learn in the process. Increase the size of your elements, use lineal elements, simplify your geometry to have something very simple and easy to understand what can be wrong. Once you get your model solving as you want, then start to reduce elements and complexity.
  
  If you want to use Mecway as preprocessor do the mesh and groups in Mecway and then in a separate input file writte the material and boundary conditions for your problem. Then for every iteration you need only to update the mesh file.
  
  Regards
• Sergio

  August 2017

  I'm using constantly Mecway as a postprocessor for Calculix without problems (only has to take care of the unit as it assume that the .frd will has Newtons and meters).
  
  Surely you have a problem on the input file, my advice is that you must reduce the size of your model to have something that solve as quick as possible in order to be able to make several tries and learn in the process. Increase the size of your elements, use lineal ones, simplify your geometry to have something very simple and easy to understand what can be wrong. Once you get your model solving as you want, then start to reduce elements size and add complexity.
  
  If you want to use Mecway as preprocessor do the mesh and groups in Mecway and then in a separate input file writte the material and boundary conditions for your problem. Then for every design iteration you need only to update the mesh file.
  
  Regards
• Victor

  August 2017

  Several things are unclear:
  
  Is it the internal solver (not CCX) that can't solve, or is it CCX run through Mecway? I'm concerned if there are models that can run in CCX from the command line but not through Mecway.
  
  How are you opening the .frd file? It doesn't get picked up automatically unless you're solving through the Mecway UI. You can open a .frd with File->Open or File->Import It also shouldn't have the components in the Solution branch of the outline tree. Having that but no solution sounds like a strange failure happened.
  
• Rusticus

  August 2017

  Sergio -
  
  Thanks for the confirmation that using Mecway for pre- and post-, with CCX on the command line as the solver, is an appropriate approach. My current problems may be units related, as I was able to open the ".frd" directly late yesterday, but the model looks like an origami project gone wrong. My geometry cannot be identified in the mess. Perhaps a simple scaling will suffice, or perhaps I will need to convert my Mecway model to SI units.
  
  Regarding solving quickly, CCX (run on the command line - the *CENTRIF load demands it) solves within a few minutes. Mecway's solver ran overnight, so I don't know how long it took to fill my hard drive, but more than 2 1/2 hours. The CCX runs are quick enough for me, at the moment.
  
  I had supposed that the results of the command-line CCX run (as an ".frd") could be moved to the same folder as the ".liml" and that Mecway would display the result which are in the ".frd", but this doesn't appear to be the case. Based on observed behavior, I now conjecture that results are stored in both the ".liml" and the ".frd" when CCX is called from within Mecway, but that Mecway only reads the ".liml" data (unless directed to open the ".frd"). Perhaps you can confirm this?
  
  Thanks also for the recommendation that I start with simplified models. As background, I did start with very simple models (coarsely meshed 2-D axisymmetric, then revolved hexahedra, as rather crude first approximations). I also worked out (with assistance from the forum) how to model an interference fit between the collar and shaft as a thermal load. The simplified axisymmetric and revolved models (stepped wall torque tube and circular H-section shaft collar) solved plausibly, and solutions did not change much as mesh size was decreased.
  
  I am now trying to use an automesh of simplified actual collar geometry (most holes and most fillets removed), imported via STEP file and currently modeled as a single conjoined solid, though it is physically two identical halves bolted together. The total number of elements, shaft and collar included, is about 218,000. I imagine that the number of elements could approach 1E6 as I refine the model.
  
  My shaft collar is not axisymmetric, though it is planar symmetric. I want to get the STEP-derived mesh to solve so that I can locate any potential "hot spots" where stresses are concentrated or deflections are unacceptably large under the combined interference fit and centrifugal loads. Once I am convinced the STEP-derived shaft collar mesh solves plausibly, I can model the two collar halves separately, and add the threaded fasteners (modeled as simple beam elements) which will hold the two halves of the collar together on the shaft. That will give me some insight into how the bolt loads are distributed - how even is the load sharing among them and whether the anticipated uneven loading leads to problems within the shaft collar or to unacceptably high loads in some bolts.
  
  Lastly, I will attempt to duplicate the loading seen by the collar when mounted on the flexible thin-walled torque tube in the case when it is mounted on a much stiffer (radially) balancing and spin test arbor, by correctly sizing the arbor to have a lesser interference. I don't want to either under- or overload the collar or mounting bolts during the balancing and spin test. It should be a representative test of operating conditions.
  
  Does this seem to be a reasonable path to the end goal? It has been a very long time since I last did any FEA, so I might be leading myself down the primrose path!
  
  This may be a lot to chew for a first project in Mecway, but it's what I find on my plate, at the moment.
  
  Can you elaborate on what you mean by writing boundary conditions and materials in a separate file from the mesh and groups? I am uncertain of the mechanics of doing this. Is there a spot in the Mecway manual I should reference (or the CCX manual)? It sounds like this could simplify my life.
  
  Thanks again for your very helpful advice.
  
  Rusticus
• Rusticus

  August 2017

  Victor -
  
  To clarify, Mecway was unable to solve using its internal solver. I am applying a centrifugal load (15,000rpm) to my assembly, so I had tried the internal solver first.
  
  I am not able to call CCX from Mecway with the centrifugal load applied, since the "hooks" do not yet exist to translate that load case to the ".inp" file.
  
  Your worry is for nothing, I think - comparing apples to oranges - since I cannot run both solvers from inside Mecway for my load case.
  
  Thus, to run in CCX from the command line, I hand modified the ".inp" generated by Mecway when CCX is the selected solver, with a gravity load applied (to identify the *EAll element group to which I want to apply the centrifugal load). Then, I simply added in my desired *CENTRIF load between the *STEP and *END STEP lines (note to other users: Notepad++ handled the large file [~2 million lines] with aplomb).
  
  It doesn't surprise me that there are differences in memory management or solve time between the two solvers. I imagine that there is little code in common between the two, beyond some basic linear algebra libraries, perhaps.
  
  I had supposed that simply placing the resulting ".frd" adjacent to my ".liml" in the file structure would load the results in Mecway, but I now realize I must directly open the ".frd". I am now trying to sort out what may be a units discrepancy, based on Sergio's comments, above. I may end up converting my CREO model (in inches) to SI units (meters), re-exporting the STEP, and re-meshing, to get the native ".frd" units to match.
  
  Thanks for your assistance, and your vigilant involvement in the forum. Thanks also for your patience with me as I try to reacquire a measure of competence in FEA after a long hiatus. I feel as if I've jumped into the deep end, and have had to rely on the forum members to fish me out! On the other hand, I've made much more progress in Mecway than I had in Z88 Aurora, which seems to be built more for pedagogical applications than industrial. Horses for courses...
  
  Rusticus
  
  
  
  
• Sergio

  August 2017

  1) If you are working with an assembly, mi advice is try to solve within Mecway using CCX as solver. In this way you will be able to hide/show every component of the assembly during postprocessing (for example to see the stress in a unique bolt), something not possible if you just import the .frd result.
  
  2) All CCX cards and options not included in Mecway interface can be used by means of CalculiX Custom Content option (look in the model tree). A very powerfull solution to make complex models. Is what you call "hooks"
  
  3) When you use Calculix as solver, the results are writted first by the solver in the .frd file and then Mecway reads it to atacch to the .liml file. There is an option to keep all files in the same folder as the .liml, otherwise will be stored in a Windows temporal folder.
  
  4) Working with 1e6 elements on Mecway can be a little tricky... for any model rotation or zoom you'll have to wait, worst thing is sometimes Mecway writtes the model and you can show it, then when you save it and try to open it... no way to open it, you loose all your model. It happens to me several times with smaller models but with several increments, about 1.2 GB file, and with a 8GB ram machine cannot open it, so take care with such a big models.
  
  5) Coming back to FEA after years, and with a new solver and preprocessor... a real challenge, you should go from basic models to complex ones.
  
  6) About writting BC and mesh in two files, you must use the *INCLUDE card at the begin of the input file with the boundary conditions. This is part of CCX, so look on it's documentation. In this way you will have a big input file with nodes/elements/groups, and a second one only with the boundary conditions and material, then very easy to work and understand. But better look 1) and 2)
  
  7) Same opinion on Z88 :-)
  
  Can you share a picture of your model at least?
  
  Regards
• Rusticus

  August 2017

  Sergio -
  
  Thanks very much for helping me again.
  
  Per your request, I've included a JPEG showing a short section of the shaft with the two piece collar mounted to it. There are pockets machined into both sides of the collar. The pockets will hold power coils, printed circuit boards and more. The company I work for supplies telemetry systems to broadcast data from rotating and reciprocating assemblies to a radio receiver. This design is for measuring strain on the shaft (two redundant channels), but we also do temperature, displacement, pressure, etc. on piston crowns, connecting rods, wrist pins, bearing journals, clutch plates, torque converters blades, etc. - anywhere inconvenient. No slip rings and brushes or other physical connections are required, because power is coupled inductively and the signal is transmitted by frequency modulated radio. Sometimes, the data signal is also coupled inductively, for very high bandwidths.
  
  Unfortunately for me, the customer for this job constrained our mounting options because of the test fixture they will be using. I would have preferred to use a single continuous ring, with tapered split collets to wedge between the telemetry ring and the shaft. But, the shaft will already be attached to fixed equipment via flex pack couplings on both ends, so we were forced to clamp over the shaft circumference, with no access over the ends of the shaft. No key way is possible, due to the very thin wall of the torque tube (0.1"/2.54mm) and the applied torque. A fine spline may have been possible from a technical standpoint, but from a political standpoint could not be pursued - too many levels of contractors and sub-contractors, too many cooks with opinions regarding the correct recipe. The friction will be assisted by Loctite sleeve retainer as insurance, but the mechanical interference between the shaft and collar should theoretically suffice to restrain against angular slip, with reasonable safety factor. Belt and braces...
  
  Regarding 1 and 2, I will experiment with entering the *CENTRIF load in the custom model definition, as you have suggested. I had briefly experimented unsuccessfully with this, before switching to modifying the ".inp" directly. Using the CCX custom model will also probably avoid the length units problem I seem to have encountered when opening the ".frd" directly in Mecway.
  
  Thanks for the tip in point 3. I had found that check box at some point in playing with various settings, but it was good to make sure I knew about it.
  
  Per your point 4, I will keep the model as small as possible. I will also try to only refine the mesh in "interesting" areas of the model, to keep the element count down.
  
  Re point 5, yes, it is not easy, but it's good to bend my brain a bit, make it stretch.
  
  As for your point 6, I was not aware of the *INCLUDE card. I will investigate and experiment further.
  
  Re your point 7, I think Z88 Aurora is nice for a review of the theory of FEA, especially with Reig et al. as a reference. But, I found that a real world problem which wasn't just a simple truss became intractable. It was a good place to start, though, when just getting back into FEA.
  
  Thanks again for your kind assistance. I hope to be able to repay it someday, or at least help someone else at some time.
  
  Rusticus

  shaft_and_collar.jpg 14.5K
• Sergio

  August 2017

  Pay attention that no matter the units that you are using in your model, in the CCX custom data dialog box must be entered in meters and Newtons!
• Victor

  August 2017

  > I was able to open the ".frd" directly late yesterday, but the model looks like an origami project gone wrong.
  
  From that description, it sounds like the 3-digit exponent problem which happens with some builds of CCX (possibly including the one with Mecway, I'm not sure) run from the command line without the required PRINTF_EXPONENT_DIGITS=2 environment variable set.
  
  I also recommend running it through Mecway for the reasons Sergio said as well as that it will set this environment variable, take care of units automatically (except for hand-written CCX cards), and should generally be easier.