Learning Forum

[Bas_vD]

Hi,

Currently I'm trying to get some nodal data into a CSV format, such that it is immediately proccesable by Matlab or Excel for specific weld calculations. Previously we used NLIST and NFORCE to export the nodal data, but this creates files with a lot of unwanted text. Since the column sizes differ per export, errors occured in the Matlab or VBA script while processing these text files into usable array's. So, the idea was to export the data as a table only consisting of numbers directly from Ansys by using apdl. The table should consist of NodeNumber, LocX, LocY, LocZ, Fx, Fy, Fz (nodal forces, no constrained nodes) (or two tables are fine as well: Node,LocX,LocY,LocZ and Node,Fx,Fy,Fz)

Now comes the issue, I've came up with the apdl code below, but this turns out to be very very slow when adding the FSUM into the DO loop. Is there a way to speed up this proces, or is there a better way to write the NFORCE data into a clean table only containing the nodal force data as separated arrays. Thanks!

/Post1
set,last

csys,0
clocal,99,1,0,0,0,0,0,0 !creates a cylindrical coordinate system
csys,99 ! Make this 0 for XYZ and 99 for Cylindrical frame

cmsel,s,Named_Selection_of_multiple_edges,NODE !select nodes in Named selection

*GET,node_nr,NODE,0,count     ! get total number of nodes
*GET,node_min,NODE,0,num,min  ! select node with minimum node number in selection
*dim,node_vec,,node_nr  ! create vector with nodes
n0=node_min
node_vec(1)=n0

*do,i,2,node_nr
n0=ndnext(n0)
node_vec(i)=n0
*enddo

*DIM, ANODES, TABLE, Node_nr, 3 !Define table to save coordinates

*DO, J, 1, Node_nr,1
*GET, ANODES(J,1), NODE, node_vec(J), LOC, X ! when using Cylindrical frame X stands for R
*GET, ANODES(J,2), NODE, node_vec(J), LOC, Y ! when using Cylindrical frame Y stands for Theta
*GET, ANODES(J,3), NODE, node_vec(J), LOC, Z ! when using Cylindrical frame Z stands for Z

*ENDDO

csys,0 !reset coordinate frame to XYZ
set,,,,,3.525                   ! Set the specific time step in [sec] that needs to evaluated. Use 'set,last' for 1 step simulation

!Defining force vectors:

*DIM, AFORCE, TABLE, Node_nr, 3

*DO, ii, 1, Node_nr,1

nsel,s,node,,node_vec(ii),node_vec(ii)

FSUM

*GET, AFORCE(ii,1), FSUM,, ITEM, FX
*GET, AFORCE(ii,2), FSUM,, ITEM, FY
*GET, AFORCE(ii,3), FSUM,, ITEM, FZ

*ENDDO

/OUTPUT, OutputFile,csv

*VWRITE, node_vec(1,1),ANODES(1,1),ANODES(1,2),ANODES(1,3),AFORCE(1,1),AFORCE(1,2),AFORCE(1,3)
%g, %g, %g, %g, %g, %g, %g           

/output

[dlooman]

I'm surprised to hear you say that the noforce command has too much text.  The sample below could be cut and pasted directly into excel or the output could be redirected to a file and opened in Excel.   The nwrite command output (file.node) is similarly compact and can be opened in Excel.

   NODE      FX         FY         FZ  
       1   0.2313E-01 -0.7179E-02  0.4996E-02
       2  -0.2313E-01 -0.7179E-02 -0.4996E-02
       3   0.2145E-01 -0.4194E-02  0.7116E-02
       4    0.000     -0.4624E-02   0.000    
       5  -0.2145E-01 -0.4194E-02 -0.7116E-02
      46  -0.2313E-01 -0.7179E-02  0.4996E-02
      59   0.2313E-01 -0.7179E-02 -0.4996E-02
      67   0.2145E-01 -0.4194E-02 -0.7116E-02
      68    0.000     -0.4624E-02   0.000    
      69  -0.2145E-01 -0.4194E-02  0.7116E-02
      91  -0.4225E-01 -0.1570E-01  0.2764E-02
      92  -0.4290E-01 -0.1632E-01   0.000    
      93  -0.4225E-01 -0.1570E-01 -0.2764E-02
     121   0.4225E-01 -0.1570E-01 -0.2764E-02
     122   0.4290E-01 -0.1632E-01   0.000    
     123   0.4225E-01 -0.1570E-01  0.2764E-02
     145  -0.3650E-01 -0.1045E-01  0.3600E-02
     146  -0.3678E-01 -0.1133E-01   0.000    
     147  -0.3650E-01 -0.1045E-01 -0.3600E-02
     148    0.000     -0.1152E-01   0.000    
     149    0.000     -0.1233E-01   0.000    
     150    0.000     -0.1152E-01   0.000    
     151   0.3650E-01 -0.1045E-01 -0.3600E-02
     152   0.3678E-01 -0.1133E-01   0.000    
     153   0.3650E-01 -0.1045E-01  0.3600E-02

[Bas_vD]

 

Thank you for your reply,

When I use the following APDL code in a command, I get the following txt file or csv file:

!use this output file for the Matlab script, set the specific time!
/output,nfor,txt           (or csv)
set,,,,,3.525
NFORCE

which gives the following Text or Csv file:

USE LOAD STEP     0  SUBSTEP  LAST    FOR LOAD CASE 0 
 USE DATA SET FOR TIME OR FREQUENCY=  3.5250    

 SET COMMAND GOT LOAD STEP=     0  SUBSTEP=     0  CUMULATIVE ITERATION=     0
   TIME/FREQUENCY=  3.5250    
 TITLE= (left blank)                

 *** MAPDL – ENGINEERING ANALYSIS SYSTEM  RELEASE 2024 R1          24.1     ***
 Ansys Mechanical Enterprise PrepPost              
(left blank company data)   07:36:14  JAN 28, 2025 CP=      7.484

 (left blank company data)                     

 

          ***** POST1 NODAL TOTAL    FORCE SUMMATION *****

 LOAD STEP=     0  SUBSTEP=     0

  THE FOLLOWING X,Y,Z FORCES ARE IN THE GLOBAL COORDINATE SYSTEM

   NODE      FX         FY         FZ         MX         MY         MZ  
    7868   -664.7      -5860.      -896.6      0.3906E-02  0.1367E-01  0.7324E-02
    7869    12.83      -5320.       2457.      0.9766E-03  0.1660E-01  0.1063E-01
    7870    157.6      -5448.       2596.     -0.4883E-03  0.1660E-01  0.1107E-01
    7871    77.03      -5343.       2341.     -0.1221E-02  0.1562E-01  0.1096E-01
    7872   -235.4      -5050.       2319.     -0.1221E-02  0.1465E-01  0.1086E-01
    7873   -687.0      -4545.       2354.     -0.1587E-02  0.1367E-01  0.1067E-01
    7874   -1255.      -3858.       2388.     -0.1556E-02  0.1074E-01  0.1025E-01
    7875   -1900.      -3046.       2381.     -0.1389E-02  0.9766E-02  0.9476E-02
    7876   -2522.      -2175.       2304.     -0.1038E-02  0.6836E-02  0.8408E-02
    7877   -2973.      -1324.       2142.     -0.4883E-03  0.4395E-02  0.7172E-02
    7878   -3109.      -588.0       1906.       0.000      0.2930E-02  0.5814E-02
    7879   -2999.      -886.7       1460.      0.7324E-03  0.1709E-02  0.4593E-02
    7880   -2465.      -925.6       642.9      0.7324E-03  0.1221E-02  0.4196E-02
    7881   -4121.      0.1124E+05   1463.      0.9766E-03  0.9766E-03  0.1801E-02

So I’m not seeing what you have shown in your reply. And this unwanted text repeats every 50 nodes or something like this. I just want a clean list as you’ve shown. What am I doing wrong then? Excel or Matlab could get rid of this text and write the node numbers, locations and forces into arrays, but the problem is that the columns change size for different load cases. When a complete column (FX, FY, FZ) contains a single scientific number (1.0E+05) or not, the column size changes and Matlab or Excel cannot handle the text file or csv file anymore, so an adjustment within the code is required then. This is unwanted as we want to write a Matlab runtime executable for this. So it is way more convenient to input a clean data file, most preferrably already separated in arrays. Next to the approach from covering it from the Ansys APDL side, I'm also trying to cover it from the Matlab/Excel side. I'm diving into the code in VBA and Matlab that converts these txt or csv files into workable array data. Since this is written earlier by someone else, I'm not completely into it. But I guess there should be an option to not count the amount of 'spaces' that need to come into a single array, but use another way of separating. So I'm working on that as well. Still, in my opinion the clean way is a clean export from Mechanical, which should be possible since all the nodal data is available. 

Moreover, the NWRITE command does give a clean list of only nodes and nodal data, but will not work for us in all cases, since it only exports global Cartesian data, we mostly use this nodal data with cylindrical coordinates. But for the coordinates I’ve got a working script that runs in seconds. The force data is the one that changes the process time of the script from seconds to at least 15 minutes when using the FSUM command within the loop. 

 

[dlooman]

The /output command should go just before the nforce command so you don't get the command echo from the set command.  I was hoping the headers could be suppressed with /header,off,off,off,off,off,off but I till got the Version information and the output description.

[Bas_vD]

Thanks again for your reply. So basically, for the nodal force data this does not work as I was hoping for. Then my first question still stands, is there a way to speed up the process in the DO loop when using FSUM or is there another way of exporting this nodal force data directly into a clean table? It feels a bit weird that the data is available within seconds via NFORCE at nodal level, but there is not a command to get it extracted into arrays like the GET, NODE, RF,FX for constrained nodes.

Just examining my options in Mechanical, I haven’t used a python script in it before, but could that for example solve it?

EDIT: When using PRNLD instead of NFORCE, you're able to get rid of the majority of the text with /header,off,off,.. Unfortunately the way of exporting the data is a little different here, there is a possibility that two scientific notations do not have a 'space' as a delimiter, which makes it pretty hard to use for postprocessing in Matlab. NFORCE seems to have a space between every column value, that at least gives me an option to split the string into arrays.

Node data in PRNLD: 8046  0.13817E-003 0.19819E-003-0.28551E-004-0.34180E-002-0.17090E-002 0.10117E-001

Node data in NFORCE: 8046   0.1382E-03  0.1982E-03 -0.2855E-04 -0.3418E-02 -0.1709E-02  0.1012E-01

Can PRNLD be influenced on the scientific notation or its delimiter?

For now, I am seeing basically two options: Use NFORCE and create the required arrays in Matlab via coding that separates on spaces and not on column width. Or use a faster script in apdl or python if you see any possibities there. 

 

 

[dlooman]

I don't know why fsum node by node is so much slower than nforce.  Just out of curiosity, how many nodes are you looping through and how long does it take?  There could be a way to use Python or something called DPF, but I'm not familiar with them.  You might get some help on those with a new post. 

[Bas_vD]

1624 for the selected edges of this particular model. The edges are the perimeter of a squared tank wall, where the nodal force data on the edges is extracted and used in Matlab (or Excel) for further calculations. 

The NFORCE command took around 10-20 seconds to run, where the FSUM loop at least ran for 15-20 minutes. I did not counted the minutes exaclty, but at least the difference can be easily seen..

At this moment I'm prioritized to another project, so I will pick up this coding subject a bit later. When I do I will first focus on the Matlab side, when that gives no solution, I will dive into Python or DPF then, but same as you, I'm not familiar with those. 

Unfortunately without a solution at this moment, but at least thank you for your time!

[dlooman]

Is it worth a lot of trouble to save 20 minutes!?

[Bas_vD]

This will be used a standardized tool for the coming years, so yes if the time can be reduced to less than a minute with respect to 20-30 minutes (1600 nodes could also be 2000 or more) it is definitely worth some investigation into a faster way. It does not feel as trouble, more as a learning curve and a challenge to get more efficiency into the tool ;) 

Thanks, 

Bas

[dlooman]

I made a test and I see that fsum is very slow.   I found that the prrfor command obeys the /header specifications, so you could try that if the nodes you are interrogating are constrained:

/header,off,off,off,off,off,off 
/out,prrfor,out
prrfor,f
/out 

[dlooman]

/post1
set,last 
 
nsel,s,loc,x,0

/out,nforce_out,txt
nforce
/out

*get,n_count,node,,count 
*dim,nforce_vals,array,n_count,4

*vread,nforce_vals(1,1),nforce_out,txt,,JIK,4,n_count,1,17
(F8.0,2X,E11.5,X,E11.5,X,E11.5)

*cfopen,nforce,data 
*vwrite,nforce_vals(1,1),nforce_vals(1,2),nforce_vals(1,3),nforce_vals(1,4)
(F8.0,2X,E11.5,X,E11.5,X,E11.5) 
*cfclose

[Bas_vD]

Hi, thanks for your replies,

The nodes are not constrained so PRRFOR cannot be used. PRNLD however can be used and also obeys to /header, as can be read in my posts above. The drawback is that PRNLD has no white spaces between the nodal data, making it harder to split the data. 

With respect to the coding in your last post, I tried it and ended up with the following error:

 *** ERROR ***                           CP =       7.578   TIME= 15:31:34
 *VREAD error in data read. 

It seems that it is able to generate arrays for the first amount of nodes, but after approx. 50 nodes (I haven't counted the rows) the header data returns and this screws up the arrays (where the empty rows are most likely the problem?), resulting in the error. If I change the maximum number in vread, which is 'n_count' to 15 or every other number before the header data returns, the nforce.data file is created, if I make it 100 or n_count the error above appears. So unfortunately this will script will only will work for a limited amount of nodes. 

However, knowing this, it is possible to combine the PRNLD (with /header command) with this script and define the format by counting where to delimit. The only uncertainty that remains is that column width sizes of PRNLD appear to differ, so, this requires awareness and the ability to change the script if required. It would be nice if a white space could be used as delimiter. That will always work whatever the column width is. But I guess it is not possible to add an extra white space between columns into the PRNLD printing format or can I? Still, using this approach and thus the column format by counting, it is possible to create the required data file faster then with FSUM. It took around 10 seconds. Altogether, we are getting somewhere, and we got a workaround. 

The PRNLD row that makes the white space delimiter option useless (node 8046, between FY and FZ there is no white space):

    8044   4773.6      -21166.       4332.9     
    8045   2369.7      -17755.       15486.     
    8046  0.13817E-003 0.19819E-003-0.28551E-004
    8047   9823.1      -11008.       19892.     
    8048   3728.2      -4302.7       2660.7 

Your script adjusted:

 

/out,nforce_out,txt

/header,off,off,off,off,off

prnld,F,0,

/out

 

*get,n_count,node,,count 

*dim,nforce_vals,array,n_count,4

 

*vread,nforce_vals(1,1),nforce_out,txt,,JIK,4,n_count,1,10

(F8.0,X,E13.5,X,E12.5,X,E12.5)

 

*cfopen,nforce,data 

*vwrite,nforce_vals(1,1),nforce_vals(1,2),nforce_vals(1,3),nforce_vals(1,4)

(F8.0,X,E13.5,X,E12.5,X,E12.5) 

*cfclos

[dlooman]

So we're good?  I hesitated to recommend *vread because it isn't user-friendly.

[dlooman]

Rereading your post, I see that the absence of a space is inconvenient in the PRNLD format.  I found I can prevent the header from repeating with the command /format,,,,,1000  or similar large number.

[Bas_vD]

Yes! That was exactly what I needed. Your remark about the /format was helpful for the NFORCE command to get rid of the headers in between, but unintentionally even more helpful for the PRNLD command. With this /format command I can fix the column size of the PRNLD output. By choosing a too large number I'm always safe that the nodal force data will fit and not changes the column size (15 instead of default 13). By fixing this size, I am able to use the splitting by counting instead of splitting by white space. The NFORCE command did obey to the LINE variable, but not to the column width, so for me the PRNLD is the better choice. Due to the fixed column size in PRNLD or the improved NFORCE without unwanted text in between, my problem is solved and I got multiple ways (in apdl or Matlab) to get the data ready for postprocessing. 

The adjusted code to solve the problem within apdl (which runs in seconds):

/out,nforce_out,txt
/header,off,off,off,off,off
/format,,,15,,5000
prnld,F,0,
/out

*get,n_count,node,,count 
*dim,nforce_vals,array,n_count,4

*vread,nforce_vals(1,1),nforce_out,txt,,JIK,4,n_count,1,17
(F8.0,X,F15.5,X,F15.5,X,F15.5)

*cfopen,nforce,csv 
*vwrite,nforce_vals(1,1),nforce_vals(1,2),nforce_vals(1,3),nforce_vals(1,4)
%G, %F, %F, %F
*cfclos

Thank you for your help and have a nice day!