hexagon logo
Register Sign in
  • State Not Answered
  • Replies 3 replies
  • Subscribers 12 subscribers
  • Views 120 views
  • Users 0 members are here
Options
Related

Serious AView python bugs found, reported

christopher.churchill
​I have uncovered a few bugs in AView related to using python in large models, some quite serious. I opened up tech support cases, and they have all been acknowledged and reported but I figured it would be good to warn other unsuspecting users ;-) I don't know where the crossover in number of parts/forces causes bugs, but 500 parts/3000 markers/3000 forces definitely does the trick.
 
If you happen to create a model with hundreds of parts (see attached example) then you will start to see some very strange behavior in python. The command language is still stable.
 
  1. Adams.getCurrentModel().Markers[0] or any other __get_item__ like call to a manager with integer argument will crash AView, fixed in 2018
  2. Some filters on dictionary queries will crash AView, for example  Adams.getCurrentModel().Parts.values('RigidBody'), not fixed yet
  3. Most seriously, the manager keys() and values() functions only return the first 25-30 entries, making it impossible to modify large models without keeping your own separate pointers to objects as you create them! I'm really hoping this is fixed in 2018.
  4. icons turn on in the view window after any python command, no a big deal but with large models with thousands of markers it gets pretty annoying- not fixed yet.
  5. The AView model navigation tree gets very unstable after using python to create a large model, crashing randomly as I use it.
Attached Files (2)
  • 0
    I would have to lie, if you expect me to say I'm surprised.
    Since I work with ADAMS for now 22 years they somehow always had the bad habit that new stuff did not work out of the box. It became worse after MDI was acquired by MSC and marketing superseded technical development (i.e. first sell a product's idea rough draft and then develop a working version)
     
    Especially the AMD itself is horribly slow/unstable if it comes to "big" models.
    Obviously MSC is mostly testing with a one-part pendulum, but on models with discrete formulations that result in lots of parts & forces, they've always been weak.
    And "big" starts at even a few hundred elements in their eyes.
     
    BTW: We've just had a training on the new Python lib and these days I had to replace some existig SDK C-code to puke out a bunch of requests from a list of hardpoints/markers.
    Guess what I used ? Exactly: Not the new Adams lib, but the old fashioned way with creating the aview command as a string and using the old aview_main functions.
    Main reason was that I still need it to work in 2014.0.1 and 2015.1.2 .
  • 0
    Has this improved in newer versions? In 2017.2 I'm getting these issues and its quite aggravating.
  • 0 in reply to andrew.ng

    Yes, these issues were fixed in version 2018 with resolved bug reports including ADMS-41487, ADMS-43322, and ADMS-43643.  I hope this helps.

© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement