Abstract
The author is to be congratulated in producing a paper for the journal on an important aspect (hydrodynamics) of a design, which was taken to a considerable level of definition before not being proceeded with. The fact that we so rarely get visibility of the thinking and effort behind “abortive” designs – so very little was allowed to be preserved of the cancelled CVA01 of the 1960s – and that this can be compared to the separately evolved, subsequently fully design and, now in 2017, about to go into service QUEEN ELIZABETH (QEC) carrier, makes this a very worthwhile document for the Transactions.
 Not only can the various detailed conclusions on the hydrodynamically related design choices be read for their input to the BAE Systems alternative to the Thales design, that was finally developed into the QEC (see S Knight’s 2009 RINA Conference paper), the paper also provides general insights into the interaction of one specific topic (hydrodynamics) with wider design developments. This can be instructive to future designers of complex ships – not just aircraft carriers. It could be argued that despite the growing capabilities of CFD tools, that there still appears to be a need for substantial model testing of discrete elements of the hydrodynamic design, as described. Would the author like to comment as to whether he sees this dual need for CFD and physical model testing likely to continue whenever new designs “are just that little bit too different” and how one might judge the latter?
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.