The meaning of MPC184 keyopt(2) was changed rather significantly between 9.0 and 10.0, with the result that some legacy input from 9.0 no longer runs correctly in 10.0. Can't the software developers keep the existing keyopts and just add to the end of them without changing the order? At least then our historical files would continue to run. Please could an explanation be given as to why the 2D option was dropped and why the actual use of the keyoption was changed?
We agree that it is very important to support our customers` legacy input, and normally we do not consciously implement changes that we know will cause problems with legacy models. In this case, an exception was made to our usual development practices, because it was decided that the advantages of changing keyopt(2) significantly outweighed the disadvantages. Some of the considerations that affected this decision included:
` The MPC184 elements are a relatively newer set of elements and we are currently adding more to this set (particularly the joint elements).
` We made a decision to switch the defaults (from Lagrange Multiplier method to direct elimination method) in view of "significantly better performance". In particular, for the rigid beams and links with the direct elimination technique, we are now able to use the PCG solver as well. We have also provided access to the Lagrange multiplier method of implementation in case the user wants it. The switch is an easy one. We made a special effort to bring this change to users` attention in the Release Notes.
` We have noticed that the 2-D option is not very widely used and when used does not really provide much insight. This is particularly true for the flexible multibody dynamics simulations. Our past experience indicates that three-dimensional simulations for FMBD are the ones that are widely used.
` Eliminating the 2-D option also enables us to provide a much cleaner interface to the user. It has freed up the keyopts that we can use to design a better user interface for our future needs and goals. It enables us to maintain consistency in the way we present the user interface and also keeps our coding efficient and relatively maintenance free. If we ever need to include the 2-D option we will do so in a more consistent way.
We agree that we should not be making user interface changes from one release to the next. But in this case, we did so after much deliberation. We had to takeinto account the evolution of our future development and presentation of a consistent and easy-to-use user interface. We apologize for any difficulty that this change has caused you, and we hope that the continued improvements in MPC184 will make the change worthwhile to you in the long term.