hexagon logo
Register Sign in
  • State Not Answered
  • Replies 2 replies
  • Subscribers 4 subscribers
  • Views 20 views
  • Users 0 members are here
Options
Related

Is it possible to combine hardware resources via DMP for sparse decomposition?

markus.zimmer
The required ram during the sparse decomposition in the DOM9 module easily exceeds the available resources. On our compute cluster the ram per node is limited to 120GB. The plan was now to combine resources of several nodes via DMP. I was able to set up a DMP calculation by providing an host file. However, the other nodes are basically staying idle while the amount of required ram for sparse decomposition on the main host is not reduced. Is it possible to split up the sparse decomposition to several nodes or is this plain impossible?
 
Edit:
We mainly use SOL101 and 144 in SOL200. Therefore, the advantages for the frequency and modal solver do not apply for us. We really just would like to combine resources for the DOM9 module.
  • 0
    Sorry for delayed response. I just noticed this went unanswered.
     
    SOL 101 supports it. Sol 144 does not.
     
    DOM9 does not support the DMP, but sol 200 does support DMP in limited way as described below. You will find this under DOMAINSOLVER executive control description in the QRG.
     
    In SOL 200, design sensitivity calculations may be performed in a distributed parallel
    environment in SOL 200 with the DSA keyword. It is a coarse parallel implementation that divides the sensitivity task across a number of processors so that each processes a subset of the total number of design variables. Following the sensitivity analysis and before optimization, the separate sensitivity data are appended into a global sensitivity set. Also,
     
    a. The dmp=n keyword must be specified on the Nastran submittal command where n is the number of available processors.
    b. The ACMS keyword may also be specified or modified along with DSA. For example,
    DOMAINSOLVER DSA, ACMS
     
    Thanks,
    Sanjay Patel.
  • 0
    Thank you for answering.
     
    We kept on testing in order to reduce the memory consumption of the optimisation. By testing different Nastran versions, we found out V2012 uses 20 times (!) less memory during the sparse matrix decomposition in the DOM9 module than all other versions which followed (2014, 2017, 2018).
     
    After some further research I found that a new memory management system was introduced together with version 2013. Maybe our problem is related to this change.
     
    Could you further describe what adjustments have been made to the sparse decomposition module / DOM9 module which cause this drastic increase in RAM consumption? Is it possible to tweak some settings to emulate the V2012 approach in later versions?
     
    Thanks,
    Markus Zimmer
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement