hexagon logo
Register Sign in
  • State Not Answered
  • Replies 9 replies
  • Subscribers 11 subscribers
  • Views 132 views
  • Users 0 members are here
Options
Related

Missing components in request file

Stefano.Cassara
I have defined multiple requests, many of which share a common results name (so that all the components show up under a single name). The request file is missing many components. Are there limitations to the number of requests and components that can be grouped this way?
  • 0
    I believe that the request file has them under the request name.
    You have to use the results file in xml format to get them under the results name. Therefore the difference between request name and results name.
  • 0
    The components are in fact listed under the name entered in the Results Set Name field, but some components are missing. I'll check the results file to see if they're there and how they're listed.
  • 0
    The situation gets worse with the results file. Requests are listed by Results Set Name under the subsystem name - an improvement, but ALL requests that have this name are listed, so I have multiple entries. This wouldn't be so bad  except for the fact that all these requests are identical. They list the same six components of one of the requests.
  • 0
    I can comfirm this is still a bug. Using Adams 2022.2. It happens sometimes when the "Request Name" and "Results Set Name" are not the same
     
    The .nam file is written correctly, with the [REQUEST] getting the right Results_name, and components/units are also correct. However, it is not written to either the .req nor .res file.
  • 0
    OK I just figured this out. If you keep the "Request Name" and "Results Set Name" the same when creating the request, A/View will check that the name does not already exist in your model/template, and thus won't allow you to duplicate the name.
     
    The problem occurs when you create a unique "Request Name", but choose a "Results Set Name" that matches another object in your model/template. It should throw a warning or error to not allow the Request to be created, as right now the Request is simply not written to the .req file.
  • 0
    No, that would completely defeat the purpose of allowing multiple requests to share a common results set name. I.e. to allow for more than 8 components in one results set.
    The best way to work around this problem is to skip the request file and work with the results file instead.
  • 0
    Hey Jesper,
     
    I think you are misinterpreting my comment. You can still have multiple unique Requests with a common "Results set name." But you can't use a "Results set name" if another object exists in your template with the same name. So when creating a new template object/variable, you'd have to check all Requests to see if one has a "Results set name" that matches the object/variable, and vice versa.
     
    I had a state variable with the same name as the "Results set name" I chose, and that Request did not have its data saved to file. Added an extra underscore to my "Results set name", and it fixed the problem. Let me know if you can't reproduce this issue, or need additional info.
  • 0
    OK, I see what you are saying. That should in theory be a simple fix, there should be a new entity type created in the amd database for 'Results Set Name'.
    I'll create a bug report for this.
  • 0
    Another thing about organizing request: I'd prefer to have all requests associated with a particular subsystem under one Result Set Name and only there, whether I define them myself or are created automatically when I define, say, a bushing. I am able to edit the bushing request and change the Result Set Name from (._template.bgs_bushing.name // "_disp") to Subsystem and the components names from dx to bushing_dx. If I save the template in Binary format, the changes are saved, but saving in Ascii, the changes are lost. Is there another way to organize requests better if I prefer the Ascii format?
© 2025 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement