V and V in Structural Analysis by Kotur Raghavan

 In many engineering and software activities a frequently used phrase is “verification and Validation (V and V)”. One can find a large number of articles addressing this topic. The articles focus on the essential differences between the two entities. The field of structural analysis along with finite element analysis is no exception. Considerable work has been done by NAFEMS in collaboration with ASME and many of the published work is available in the open literature. Interested readers can refer those articles for in-depth information.


Fig. 1

In this brief article, the essential aspects of V and V in the context of structural analysis and FEA are presented based on the information available in these publications.

  • o   The most fundamental fact in the present context is that one verifies a CODE, whereas simulation models are validated.
  •  o   The codes, like ANSYS and ABAQUS, are developed for facilitating simulation of practical structural analysis problems. The codes thus developed use the knowledge base from solid mechanics and numerical techniques. The former information is used for developing elements and the latter for coding the solution algorithms. The code developers need to ensure that the equations and relations available in theory are faithfully translated into the code. Thus verification is the duty of code developers.
  •  o   The codes, thus developed and verified, are used by analysts and designers for simulation of structural analysis tasks. The analysts face a major problem of choosing from a large number of modelling and solution options available within the code at his disposal. There may be pitfalls in the process. In addition, not all combinations of modelling and solution options will yield the right result. In complex problems, the proof of the pudding has to come from comparison with any available field observation or experimental data. This means to say that the analysis models need to be validated with respect to some data from the real world. Thus validation is essentially the duty of the analyst.
  •  o   What the foregoing points essentially mean is that verification is mathematics and validation is physics.
  •        Another way of looking at this: The code developer has to ask himself “am I doing the thing right?” The analyst, on the other hand,  has to ask himself “am I doing the right thing”


Comments

  1. You mention Code or Software Verification but not Solution Verification which is in the domain of the analyst to control...

    ReplyDelete
  2. Thanks Angus. I get your point. This has been referred to as "calculation verification" in the brochure issued jointly by NAFEMS and ASME. This refers to mesh adequacy assessments. This certainly is the responsibility of the analyst. I will appropriately modify the text.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. This comment has been removed by a blog administrator.

    ReplyDelete
  10. This comment has been removed by a blog administrator.

    ReplyDelete
  11. This comment has been removed by a blog administrator.

    ReplyDelete
  12. This comment has been removed by a blog administrator.

    ReplyDelete
  13. Wynn Resorts: How to Get From Casino - JTM Hub
    Your guide to Wynn Resorts in Las Vegas from JAM reviews. 원주 출장마사지 and 속초 출장안마 to Las Vegas from 의왕 출장안마 our JM 수원 출장안마 Travel Guide. Wynn and Encore 서울특별 출장샵 Las Vegas Hotel.

    ReplyDelete

Post a Comment

Popular posts from this blog

Saint-Venant’s Principle, Interpretations and Applications by Kotur Raghavan

Minimum Constraints in FEA – 4. Inertia Relief Application by Kotur Raghavan

Minimum Constraints in FEA – 5. Submodeling by Kotur Raghavan