p-elements or p-methode works with coarse mesh but with higher polinomial degree (up to degree 9), so that the geometry of the model can be normally better approximated then h-elements, that works with feiner meshing, i.e more elements. Due to the higher computational cost by using p-elements, the h-elements are in general prefered to p-elements, but it may be changed in the near future, since the computer becomes faster and faster.
Oops, forgot, the methodes are normally applied to complicated models, where analitical solutions does not exist, so the analyst is not sure about the regions with highly stress gradients.
Why does using p-elements involves more computational cost? The computational cost should be EXACTLY the same, if the same number of degrees-of-freedom (DOFs) are involved. If you want a p-element FE code to act JUST LIKE a h-element code, just fix the p-level to 2, and use the same element and meshing strategy--that is, use the same number of elements in the solutions using the two FE codes. Perhaps most h-element FE code users do not bother to check numerical convergence, and therefore do not realize that their FE solutions could be in error. Does the perception that p-elements have higher computational cost come from the fact that increasing the DOFs in a model is so easy in a p-element code that p-element users increase the DOFs automatically? This naturally leads to looking at problems that at the highest p-levels seem to have many more DOFs than is practically possible with h-element codes, so perhaps the techniques that p-element code analysts use as a matter of normal engineering practice are responsible for this misconception regarding computational cost.
Besides, even if p-elements were more computationally intensive, the efficiencies gained by using p-elements would more than make this supposed 'loss' up, even if there was one. I would guess that more than 90-95% of my time to get good FE results from analyzing any particular problem are due to problem setup and postprocessing analysis. By using p-elements, my job is much easier in the postprocessing analysis task--I know how to thoroughly (and quickly!) check for numerical error, something h-element people cannot do as quickly, efficiently or thoroughly. I know my results are good, for the model I have made. I still have to use my brain, though--reality and my model could be completely different if I don't do 'sanity checks'.
In my mind the true benefits of using a p-order solver is in the convergence of the model. I am not familiar how h-order elements provide feedback on the quality of the results. I know I feel good about the results when a convergence study was conducted, I won't accept results that do not have this as part of a report.
Convergence of discretization error is usually not where an analysis job goes bad. Far more often is the model incorfectly setup than error due discretization. And if your restricted to a p-element code you may have already lost the battle consdering the codes are usually inferior.
Computationally, I think some of what was said was in error. One of the major benefits for that the iterative p-code solver has it it can selectively refine a mesh. In general, for a properly converged model the p-code will solve faster than the h-code. Scott mentioned a good point about setting up a mesh and the time it takes.
On the other hand you if you use the p-code to converge a solution, you need to solve it muliple times. If the analyst is familiar with similar problems he can come up with a satisfactory mesh and it may solve one pass faster than several by adjusting the order and checking convergence.
While I have seen lack of convergence botch up problems, if the analyst doesnt know how to achieve convergence and needs a p-code to do it, your probably screwed anyway.
Actually both of h- and p-methode have advantages and disadvantages that are not easy to be compared. Some efforts are made to combine the advantages of both methodes resulting in so called hp-methodes. One of the firm developed such methode is Altair (Comco), see an example of using this methode (hp-methode) at :
Most of the answers have deviated from the querry of exact difference.May be ican summarize:
p-version ;polynomial order is increased, Element forumation changes
h-version: elemnet size is altered
Both these depend on error levels. It is found that A h-refinement produces many a transition elements which may have to be formulated as degenerate elemnts this more so tends to a p-version analysis. There has always been an effect realized in terms of polynomial. but then its not specifically termed as p-version. We can say h version also has effects that a p- version causes and vice versa.
as such better go in for h-p. Zuardy is right.
raj
Over the years, I've become fluent in every commercially available FEA code, Algor, Cosmos, Ansys, Nastran, Mechanica. The single biggest problem (or limitation is a better word) with Mechanica, is one is limited in what one can do with Mechanica. I wrote my masters thesis on the P-method (Polynominal) technology so I beat this approach up for a long time, even writing my own custom code from the ground up.
In general some of the reasons I prefer FEA codes like Nastran over the Mechanica type codes are:
(a.) Mechanica is not as comprehensive as all the other FEA codes.
(b.) Mechanica isn't very flexible in what one can do with regard to auto-meshing and element formulation; for example one has more control over Rigid Links I don't believe even the current Mechanica code could handle the Rigid Links as eloquently as say Nastran.
(c.) Nastran is the defacto standard for FEA analysis results {can be a factor when working with large aerospace companies (Boeing & Lockheed) or auto manufactures (Ford & GM) }. Now I'm not suggesting Mechanica isn't accurate, but in my consulting business I typically end up having to supply solutions to these companies in the Nastran code as well as in Mechanica or any other code my clients might be using.
(d.) The solution times for a fine grid meshed H-Method (like Nastran) is probably an order of magnitude faster than an equivalent Mechanica P-Method coded model.
(e.) I can recall several Pro-E CAD models that even experienced users were not able to get Mechanica to develop an auto-mesh. With more comprehensive software tools like the ones found in Nastran we are able idealized these CAD models in a relatively short period of time. I had to due some tune-up of the idealizations but I got them.
Some of the More Obvious Downsides of Mechanica:
(a.) Pretty much stuck with Linear analysis only.
(b.) I don't think the current release of Mechanica can do either Large Deflections, Non-Linear Stress/Strain, or Resonant Vibrations with Load Stiffening. Maybe they can do that now, I would have to check.
(b.) Base Excitation for Dynamic Response [ Random & Sinusoidal ] - Not a big deal for most problems but there are many cases where one would like to subject models to variable input excitation at different points instead of *shaking* the entire model on it's supports {or Boundary Conditions}.
(c.) Mechanica's claim to fame when it was called Rasna was that one didn't need to develop detailed meshes. One only had to crudely mesh regions and Mechanica by virtue it's P-method internally updates the order of polynomials until convergence of the solution is achieved One Downside here is that one still needs to define proper patches [2-D] and hyper-patches [3-D] for the models to converge. Another downside is the length of processing time. Today's automeshing tools make the meshing aspects a moot point. With Nastran one can still do a lot more when it come to manipulating the idealization.
(d.) One aspect of the Mechanica code that I've witnessed is that some users take the idea of not needing to develop proper meshes too far and end up with solutions that aren't as good as they should be. The solution to this problem is to do lots of sample problems and spend a lot of time using the software. [Same with any other code.]
(e.) On the more practical ends, the Mechanica code has a limited element library - Nastran has a lot of flexibility in this area.
(f.) One interesting note is that when Mechanica P-Method [and the other FEA codes as well] list comparisons of their solution accuracy they compare to Nastran H-Method. Typically though every FEA code today gives good results if used properly.
The types of analysis most companies perform are typically -Linear Static's, Resonant Vibrations, and Dynamic Response to Sinusoidal Excitation. Every FEA code can do this. Mechanica included. I suppose the most attractive aspect of Nastran over Mechanica is the Comprehensive Modeling capability [ I know that word *comprehensive* covers a lot of ground], more Flexible modeling tools and Defacto industry standard.
That's about all I can come up with on the spur of the moment. Give me a call if you have any specific questions. I think this might be a good topic for one of my articles for Machine Design's FEA Update Column.
David R. Dearth, P.E.
Applied Analysis & Technology
E-mail "AppliedAT@aol.com"
The comments by forum readers regarding P-elements vs H-elements are all good. However, unless ANY geometry (complex or simple) is not properly meshed one may not obtain sufficiently accurate solutions. The comments that P-elements represent regions of high stress more accurate than do H-elements are not true in every case. If one is sloppy in the mesh definition then a P-method solution will miss regions of high stress. H-elements will also miss regions of high stress if not properly used. The REAL KEY to using any FEA code (P, H, Nastran, Algor, Cosoms, Ansys, Mechanica.... what ever) is to "KNOW THY CODE". The bottom line is that they ALL work, they ALL produce accurate solutions. The definition of the term "accurate" means that any code will produce solutions sufficiently "accurate" for one to make an engineering "decision" on whether or not to proceed with fabrication of prototypes for environmental testing. But, back to PvsH.. as a rule of thumb, globally doubling the order of a P-method solutions ==> 8 times more processing time. Doubling the number H-elements ==> 2 times more processing time. David R. Dearth, P.E.
Applied Analysis & Technology
E-mail "AppliedAT@aol.com"
