[APDL] *VGET with Element ETABLE data truncating
Good morning
I am currently post-processing a static analysis using Ansys classic, a total of 50 load steps. My model was initially created and solved in workbench and consists primarily of SOLID elements with numerous bush elements scattered throughout. I post process in classic as it makes trouble shooting easier, where you can input code line by line.
I loop though each load step and I extract various ETABLE data (consisting of max/min principal stresses), which I then manipulate to end up with maximum absolute principal stresses for each element at each load step.
When I interrogate each ETABLE, I can see the element numbers and its corresponding stress output. This is as I expected (note, I appreciate that the ETABLE data is not available for the bush elements but this is not a issue, I am currently only interested in the SOLID elements).
I then attempt to write each ETABLE to a single array, the first column being element number and subsequent columns being the max. abs. principal stress for each load step, which I intend to /OUTPUT to a CSV file and do some classical calculations:
[Element Number, LS1, LS2, ... , LS50]
It is here where I encounter an issue. When I interrogate the output array, I can see the columns of principal stresses against the corresponding element number, and up until a certain row (element number) they correlate with the appropriate ETABLE data.
All subsequent elements (i.e. subsequent rows) the stress results are reported as 0, despite them being non-zero in the ETABLEs. This happens where there is a discontinuation of sequential element numbers.
[ENUM Max. Abs. Prin. Stress]
1 ETABLE STRESS MATCH
2 ETABLE STRESS MATCH
3 ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
146480 ETABLE STRESS MATCH
146481 ETABLE STRESS MATCH
200485 0
200486 0
. 0
. 0
. 0
184681 0
For whatever reason, the element numbering is not sequential. For a total of 184681 elements, there are three distinct element number "chunks":
1-146482
200485-245055
309672-316055
My *VGET command is as follows, as the code loops through each load step:
*VGET,array_name(1,%LS%),ELEM,1,ETAB,L%LS%MAX
Where "LS" is the load step number and "L%LS%MAX" is the ETABLE name specific to the load step number.
My understanding of the *VGET is that the loop flag in field 8 (KLOOP) defaults to element number. I cannot understand why, when "VGET'ing" the ETABLE data into an array, it appears to truncate. I have used this base code for a while now for various jobs and have not seen this behaviour before.
Has anyone seen this behaviour before?
I hope I have explained this well enough, any questions, please ask.
Kind regards
Graeme Bennett
Wabtec UK
Ansys V2019 R3, Windows 10, commercial licence.
This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Graeme,
My guess is that what you are seeing is the result of a subscript mismatch due to the gaps in the element numbering. Instead of using the *VGET you may need to use a *DO loop to control your indexes.
Keith
FEA Technologies
On Oct 9, 2024, at 6:13 PM, Bennett, Graeme via Xansys xansys-temp@list.xansys.org wrote:
Good morning
I am currently post-processing a static analysis using Ansys classic, a total of 50 load steps. My model was initially created and solved in workbench and consists primarily of SOLID elements with numerous bush elements scattered throughout. I post process in classic as it makes trouble shooting easier, where you can input code line by line.
I loop though each load step and I extract various ETABLE data (consisting of max/min principal stresses), which I then manipulate to end up with maximum absolute principal stresses for each element at each load step.
When I interrogate each ETABLE, I can see the element numbers and its corresponding stress output. This is as I expected (note, I appreciate that the ETABLE data is not available for the bush elements but this is not a issue, I am currently only interested in the SOLID elements).
I then attempt to write each ETABLE to a single array, the first column being element number and subsequent columns being the max. abs. principal stress for each load step, which I intend to /OUTPUT to a CSV file and do some classical calculations:
[Element Number, LS1, LS2, ... , LS50]
It is here where I encounter an issue. When I interrogate the output array, I can see the columns of principal stresses against the corresponding element number, and up until a certain row (element number) they correlate with the appropriate ETABLE data.
All subsequent elements (i.e. subsequent rows) the stress results are reported as 0, despite them being non-zero in the ETABLEs. This happens where there is a discontinuation of sequential element numbers.
[ENUM Max. Abs. Prin. Stress]
1 ETABLE STRESS MATCH
2 ETABLE STRESS MATCH
3 ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
146480 ETABLE STRESS MATCH
146481 ETABLE STRESS MATCH
200485 0
200486 0
. 0
. 0
. 0
184681 0
For whatever reason, the element numbering is not sequential. For a total of 184681 elements, there are three distinct element number "chunks":
1-146482
200485-245055
309672-316055
My *VGET command is as follows, as the code loops through each load step:
*VGET,array_name(1,%LS%),ELEM,1,ETAB,L%LS%MAX
Where "LS" is the load step number and "L%LS%MAX" is the ETABLE name specific to the load step number.
My understanding of the *VGET is that the loop flag in field 8 (KLOOP) defaults to element number. I cannot understand why, when "VGET'ing" the ETABLE data into an array, it appears to truncate. I have used this base code for a while now for various jobs and have not seen this behaviour before.
Has anyone seen this behaviour before?
I hope I have explained this well enough, any questions, please ask.
Kind regards
Graeme Bennett
Wabtec UK
Ansys V2019 R3, Windows 10, commercial licence.
This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Xansys mailing list -- xansys-temp@list.xansys.org
To unsubscribe send an email to xansys-temp-leave@list.xansys.org
If you are receiving too many emails from XANSYS please consider changing account settings to Digest mode which will send a single email per day.
Please send administrative requests such as deletion from XANSYS to xansys-mod@tynecomp.co.uk and not to the list
Keith's comment makes sense. To overcome the gap in the element numbering
you might want to use NUMCMP command.
Good Luck!
---====
Mohammad A Gharaibeh, Ph.D.
Associate Professor
Department of Mechanical Engineering
The Hashemite University
P.O. Box 330127
Zarqa, 13133, Jordan
Tel: +962 - 5 - 390 3333 Ext. 4771
Fax: +962 - 5 - 382 6348
---====
On Thu, Oct 10, 2024 at 1:16 PM Keith DiRienz via Xansys <
xansys-temp@list.xansys.org> wrote:
Graeme,
My guess is that what you are seeing is the result of a subscript mismatch
due to the gaps in the element numbering. Instead of using the *VGET you
may need to use a *DO loop to control your indexes.
Keith
FEA Technologies
On Oct 9, 2024, at 6:13 PM, Bennett, Graeme via Xansys <
xansys-temp@list.xansys.org> wrote:
Good morning
I am currently post-processing a static analysis using Ansys classic, a
total of 50 load steps. My model was initially created and solved in
workbench and consists primarily of SOLID elements with numerous bush
elements scattered throughout. I post process in classic as it makes
trouble shooting easier, where you can input code line by line.
I loop though each load step and I extract various ETABLE data
(consisting of max/min principal stresses), which I then manipulate to end
up with maximum absolute principal stresses for each element at each load
step.
When I interrogate each ETABLE, I can see the element numbers and its
corresponding stress output. This is as I expected (note, I appreciate that
the ETABLE data is not available for the bush elements but this is not a
issue, I am currently only interested in the SOLID elements).
I then attempt to write each ETABLE to a single array, the first column
being element number and subsequent columns being the max. abs. principal
stress for each load step, which I intend to /OUTPUT to a CSV file and do
some classical calculations:
[Element Number, LS1, LS2, ... , LS50]
It is here where I encounter an issue. When I interrogate the output
array, I can see the columns of principal stresses against the
corresponding element number, and up until a certain row (element number)
they correlate with the appropriate ETABLE data.
All subsequent elements (i.e. subsequent rows) the stress results are
reported as 0, despite them being non-zero in the ETABLEs. This happens
where there is a discontinuation of sequential element numbers.
[ENUM Max. Abs. Prin. Stress]
1 ETABLE STRESS MATCH
2 ETABLE STRESS MATCH
3 ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
146480 ETABLE STRESS MATCH
146481 ETABLE STRESS MATCH
200485 0
200486 0
. 0
. 0
. 0
184681 0
For whatever reason, the element numbering is not sequential. For a
total of 184681 elements, there are three distinct element number "chunks":
1-146482
200485-245055
309672-316055
My *VGET command is as follows, as the code loops through each load step:
*VGET,array_name(1,%LS%),ELEM,1,ETAB,L%LS%MAX
Where "LS" is the load step number and "L%LS%MAX" is the ETABLE name
specific to the load step number.
My understanding of the *VGET is that the loop flag in field 8 (KLOOP)
defaults to element number. I cannot understand why, when "VGET'ing" the
ETABLE data into an array, it appears to truncate. I have used this base
code for a while now for various jobs and have not seen this behaviour
before.
Has anyone seen this behaviour before?
I hope I have explained this well enough, any questions, please ask.
Kind regards
Graeme Bennett
Wabtec UK
Ansys V2019 R3, Windows 10, commercial licence.
This email and any attachments are only for use by the intended
recipient(s) and may contain legally privileged, confidential, proprietary
or otherwise private information. Any unauthorized use, reproduction,
dissemination, distribution or other disclosure of the contents of this
e-mail or its attachments is strictly prohibited. If you have received this
email in error, please notify the sender immediately and delete the
original. Neither this information block, the typed name of the sender, nor
anything else in this message is intended to constitute an electronic
signature unless a specific statement to the contrary is included in this
message.
Xansys mailing list -- xansys-temp@list.xansys.org
To unsubscribe send an email to xansys-temp-leave@list.xansys.org
If you are receiving too many emails from XANSYS please consider
changing account settings to Digest mode which will send a single email per
day.
Please send administrative requests such as deletion from XANSYS to
xansys-mod@tynecomp.co.uk and not to the list
Xansys mailing list -- xansys-temp@list.xansys.org
To unsubscribe send an email to xansys-temp-leave@list.xansys.org
If you are receiving too many emails from XANSYS please consider changing
account settings to Digest mode which will send a single email per day.
Please send administrative requests such as deletion from XANSYS to
xansys-mod@tynecomp.co.uk and not to the list
Dear Mr. Bennett,
I think the element numbering's gaps have caused the problem.
Have you tried to use the *VMASK,selstatus command in conjunction with the *VGET,selstatus(1),ELEM,1,ESEL one? "selstatus" is the name of an auxiliary array that stores the elements' selection status. You must of course select the desired elements beforehand.
Best regards
Riccardo Testi
Development and Strategies
2 Wheeler Engines Technical Centre
Piaggio & C. S.p.A
Viale Rinaldo Piaggio, 25
56025 Pontedera (Pisa) - ITALY
Phone: +39 0587 272850
Fax: +39 0587 272010
Mobile: +39 339 7241918
E-mail: riccardo.testi@piaggio.com
-----Original Message-----
From: Bennett, Graeme via Xansys xansys-temp@list.xansys.org
Sent: Thursday, October 10, 2024 12:12 AM
To: xansys-temp@list.xansys.org
Cc: Bennett, Graeme graeme.bennett@Wabtec.com
Subject: [Xansys] [APDL] *VGET with Element ETABLE data truncating
CAUTION:This email originated from outside the Piaggio Group. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Good morning
I am currently post-processing a static analysis using Ansys classic, a total of 50 load steps. My model was initially created and solved in workbench and consists primarily of SOLID elements with numerous bush elements scattered throughout. I post process in classic as it makes trouble shooting easier, where you can input code line by line.
I loop though each load step and I extract various ETABLE data (consisting of max/min principal stresses), which I then manipulate to end up with maximum absolute principal stresses for each element at each load step.
When I interrogate each ETABLE, I can see the element numbers and its corresponding stress output. This is as I expected (note, I appreciate that the ETABLE data is not available for the bush elements but this is not a issue, I am currently only interested in the SOLID elements).
I then attempt to write each ETABLE to a single array, the first column being element number and subsequent columns being the max. abs. principal stress for each load step, which I intend to /OUTPUT to a CSV file and do some classical calculations:
[Element Number, LS1, LS2, ... , LS50]
It is here where I encounter an issue. When I interrogate the output array, I can see the columns of principal stresses against the corresponding element number, and up until a certain row (element number) they correlate with the appropriate ETABLE data.
All subsequent elements (i.e. subsequent rows) the stress results are reported as 0, despite them being non-zero in the ETABLEs. This happens where there is a discontinuation of sequential element numbers.
[ENUM Max. Abs. Prin. Stress]
1 ETABLE STRESS MATCH
2 ETABLE STRESS MATCH
3 ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
146480 ETABLE STRESS MATCH
146481 ETABLE STRESS MATCH
200485 0
200486 0
. 0
. 0
. 0
184681 0
For whatever reason, the element numbering is not sequential. For a total of 184681 elements, there are three distinct element number "chunks":
1-146482
200485-245055
309672-316055
My *VGET command is as follows, as the code loops through each load step:
*VGET,array_name(1,%LS%),ELEM,1,ETAB,L%LS%MAX
Where "LS" is the load step number and "L%LS%MAX" is the ETABLE name specific to the load step number.
My understanding of the *VGET is that the loop flag in field 8 (KLOOP) defaults to element number. I cannot understand why, when "VGET'ing" the ETABLE data into an array, it appears to truncate. I have used this base code for a while now for various jobs and have not seen this behaviour before.
Has anyone seen this behaviour before?
I hope I have explained this well enough, any questions, please ask.
Kind regards
Graeme Bennett
Wabtec UK
Ansys V2019 R3, Windows 10, commercial licence.
This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Xansys mailing list -- xansys-temp@list.xansys.org To unsubscribe send an email to xansys-temp-leave@list.xansys.org If you are receiving too many emails from XANSYS please consider changing account settings to Digest mode which will send a single email per day.
Please send administrative requests such as deletion from XANSYS to xansys-mod@tynecomp.co.uk and not to the list
Hi,
I've only seen truncation when operating arrays with different dimensions, using operations scat oder gath in *voper. The solution was always dimensioning all the involved arrays to the maximum dimension of them. But this doesn't seem to be your problem.
In the table where you show that you get values up to element no. 146481, the next element, with no results, is 200485, but the last one is a smaller one, 184681. Might be the array wrongly dimensioned?
I always use elmiqr(0,14) for dimensioning arrays used in such operations (*vget, *voper,...). This way, arrays are dimensioned to the maximum element number (whether existing or not):
*dim,whatever,array,elmiqr(0,14)
I also use masking (*vmask), otherwise, when getting values, there is a warning that there are no enough values for all positions (something like that).
But even if you're not using masking, the command should work properly.
Further, you don't need the percent sign in the index:
*VGET,array_name(1,LS),ELEM,1,ETAB,L%LS%MAX
Most likely not relevant, but who knows.
Best regards,
Félix Zabala Falcó
Meyer Werft GmbH
Papenburg (Germany)
-----Ursprüngliche Nachricht-----
Von: Bennett, Graeme via Xansys xansys-temp@list.xansys.org
Gesendet: Donnerstag, 10. Oktober 2024 00:12
An: xansys-temp@list.xansys.org
Cc: Bennett, Graeme graeme.bennett@Wabtec.com
Betreff: [Xansys] [APDL] *VGET with Element ETABLE data truncating
Good morning
I am currently post-processing a static analysis using Ansys classic, a total of 50 load steps. My model was initially created and solved in workbench and consists primarily of SOLID elements with numerous bush elements scattered throughout. I post process in classic as it makes trouble shooting easier, where you can input code line by line.
I loop though each load step and I extract various ETABLE data (consisting of max/min principal stresses), which I then manipulate to end up with maximum absolute principal stresses for each element at each load step.
When I interrogate each ETABLE, I can see the element numbers and its corresponding stress output. This is as I expected (note, I appreciate that the ETABLE data is not available for the bush elements but this is not a issue, I am currently only interested in the SOLID elements).
I then attempt to write each ETABLE to a single array, the first column being element number and subsequent columns being the max. abs. principal stress for each load step, which I intend to /OUTPUT to a CSV file and do some classical calculations:
[Element Number, LS1, LS2, ... , LS50]
It is here where I encounter an issue. When I interrogate the output array, I can see the columns of principal stresses against the corresponding element number, and up until a certain row (element number) they correlate with the appropriate ETABLE data.
All subsequent elements (i.e. subsequent rows) the stress results are reported as 0, despite them being non-zero in the ETABLEs. This happens where there is a discontinuation of sequential element numbers.
[ENUM Max. Abs. Prin. Stress]
1 ETABLE STRESS MATCH
2 ETABLE STRESS MATCH
3 ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
. ETABLE STRESS MATCH
146480 ETABLE STRESS MATCH
146481 ETABLE STRESS MATCH
200485 0
200486 0
. 0
. 0
. 0
184681 0
For whatever reason, the element numbering is not sequential. For a total of 184681 elements, there are three distinct element number "chunks":
1-146482
200485-245055
309672-316055
My *VGET command is as follows, as the code loops through each load step:
*VGET,array_name(1,%LS%),ELEM,1,ETAB,L%LS%MAX
Where "LS" is the load step number and "L%LS%MAX" is the ETABLE name specific to the load step number.
My understanding of the *VGET is that the loop flag in field 8 (KLOOP) defaults to element number. I cannot understand why, when "VGET'ing" the ETABLE data into an array, it appears to truncate. I have used this base code for a while now for various jobs and have not seen this behaviour before.
Has anyone seen this behaviour before?
I hope I have explained this well enough, any questions, please ask.
Kind regards
Graeme Bennett
Wabtec UK
Ansys V2019 R3, Windows 10, commercial licence.
This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
Xansys mailing list -- xansys-temp@list.xansys.org To unsubscribe send an email to xansys-temp-leave@list.xansys.org If you are receiving too many emails from XANSYS please consider changing account settings to Digest mode which will send a single email per day.
Please send administrative requests such as deletion from XANSYS to xansys-mod@tynecomp.co.uk and not to the list
MEYER WERFT GmbH
Firmensitz: Industriegebiet Süd, 26871 Papenburg
Registergericht: Amtsgericht Osnabrück HRB 220721
Geschäftsführer: Bernard Meyer, Dr. Bernhard Eikens, Ralf Schmitz, Thomas Weigend