Showing results for 
Search instead for 
Do you mean 
Reply

AdvNL - Translation from NAstran to Adina input

I have installed FEAMP 10.1.1 with NX Nastran 7.0.
When running a Sol601 Analysis the translation process from nastran to adina
format ( "read nastran input" comment in the *.f06 file) takes a very long
time - about 15 minutes for a 200000 Node Model.
It seems much slower then with NXNastran6.1
Does anyone have the same problem?
Is it possible to set some memory options for the adnast.exe process?
thanks
Wolfgang

8 REPLIES

Re: AdvNL - Translation from NAstran to Adina input

I have installed FEAMP 10.1.1 with NX Nastran 7.0.
When running a Sol601 Analysis the translation process from nastran to adina
format ( "read nastran input" comment in the *.f06 file) takes a very long
time - about 15 minutes for a 200000 Node Model.
It seems much slower then with NXNastran6.1
Does anyone have the same problem?
Is it possible to set some memory options for the adnast.exe process?

thanks
Wolfgang

What is your Femap Preferences setting for Max Cached Label? If you have model ID's greater than that number, that will cause Femap's performance to degrade.

You can also set the default memory for Nastran in Femap's Preferences as well or as part of the the Analysis Set.

Finally, you should post Femap questions to the Femap BBS as not all of the Femap team will find you message immediately.

Chip Fricke
Femap Applications Engineer
Siemens PLM Software
Best Regards,
Chip Fricke
Principal Applications Engineer - Femap Product Development

Re: AdvNL - Translation from NAstran to Adina input

Wolfgang,

How much memory are you specifying for NX Nastran (mem keyword)? How much physical ram is installed on your machine? If you can provide output files (.log/.f04 and .f06), I can look into it further.

BTW, you can specify memory for adina independently from NX Nastran using the NXNA_MEMORY environmental variable. See Remark 6 under "SOL 601,N or SOL 701" in Section 3.2 of the NX Nastran 7.0 Quick Reference Guide
--
Jim Bernard
Advanced Applications Engineer

Siemens PLM Software
2000 Eastman Dr., Milford, OH 45150-2712
www.siemens.com/plm

Re: AdvNL - Translation from NAstran to Adina input

Dear Chip and Tsbernar,
Thanks for your reply!
In the meantime I have found the reason for the very slow performance.
When working with SOL101 I use permanent constraints (and in the past also
with SOL601) to fix DOFs that are not connected to elements.
Now with NXNastran7.0 this causes the extrem slow creation of the
tmpadvnlin.dat file.
I have removed the permanent constraints on the nodes and the time for
creating the tmpadvnlin.dat file changes from 15 Minutes to just a few
seconds! (Model size ~200k Nodes)
This Problem was not present in NXNastran6.1! - Is there a new tranlation
process (adnast.exe) implemented in V7.0?
best regards
Wolfgang
PS: I have manually set the Solver Memory to 8192MB on a 64Bit XP Machine
with 16GB Physical RAM.
The max cached Label in FEMAP is set to 1e7
chip - I have posted this topic in the NXNastran Forum because I
thought that this is a solver problem. Is it possible to post a question in
two forums?

"tsbernar" wrote in message
news:tsbernar.44ung0@noreply.bbsnotes.ugs.com...
>
> Wolfgang,
>
> How much memory are you specifying for NX Nastran (mem keyword)? How
> much physical ram is installed on your machine? If you can provide
> output files (.log/.f04 and .f06), I can look into it further.
>
> BTW, you can specify memory for adina independently from NX Nastran
> using the NXNA_MEMORY environmental variable. See Remark 6 under "SOL
> 601,N or SOL 701" in Section 3.2 of the NX Nastran 7.0 Quick Reference
> Guide
>
>
> --
> tsbernar
> ------------------------------------------------------------------------
> tsbernar's Profile:
> http://bbsnotes.ugs.com/vbulletin/member.php?userid=191178
> View this thread: http://bbsnotes.ugs.com/vbulletin/showthread.php?t=41075
>
>


Re: AdvNL - Translation from NAstran to Adina input

Dear Wolfgang
In machines with more than 8 GB RAM is strongly recommend to use ILP-64 bit
NX Nastran solver. According manuals "NX Nastran executables are compiled
with a 64-bit integer size instead of 32-bits. The 32-bit integer executable
can allocate up to 8 Gb of memory, while the executable compiled with a
64-bit integer size can allocate approximately 20 million terabytes".
Best regards,
Blas.
--
~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director
IBERISA
Edificio Ercilla
Rodríguez Arias 23, 3º - Dpto. 19
48011 BILBAO (SPAIN)
Tel. (+34) 94 410 65 50
Fax. (+34) 94 470 26 34
E-mail: info@iberisa.com
WEB: http://www.iberisa.com
"AWOTEC" escribió en el mensaje de noticias
news:4b518bbb$1@bbsnotes.ugs.com...
> Dear Chip and Tsbernar,
>
> Thanks for your reply!
>
> In the meantime I have found the reason for the very slow performance.
>
> When working with SOL101 I use permanent constraints (and in the past also
> with SOL601) to fix DOFs that are not connected to elements.
> Now with NXNastran7.0 this causes the extrem slow creation of the
> tmpadvnlin.dat file.
> I have removed the permanent constraints on the nodes and the time for
> creating the tmpadvnlin.dat file changes from 15 Minutes to just a few
> seconds! (Model size ~200k Nodes)
>
> This Problem was not present in NXNastran6.1! - Is there a new tranlation
> process (adnast.exe) implemented in V7.0?
>
> best regards
> Wolfgang
>
> PS: I have manually set the Solver Memory to 8192MB on a 64Bit XP Machine
> with 16GB Physical RAM.
> The max cached Label in FEMAP is set to 1e7
> chip - I have posted this topic in the NXNastran Forum because I
> thought that this is a solver problem. Is it possible to post a question
> in two forums?
>
>
> "tsbernar" wrote in message
> news:tsbernar.44ung0@noreply.bbsnotes.ugs.com...
>>
>> Wolfgang,
>>
>> How much memory are you specifying for NX Nastran (mem keyword)? How
>> much physical ram is installed on your machine? If you can provide
>> output files (.log/.f04 and .f06), I can look into it further.
>>
>> BTW, you can specify memory for adina independently from NX Nastran
>> using the NXNA_MEMORY environmental variable. See Remark 6 under "SOL
>> 601,N or SOL 701" in Section 3.2 of the NX Nastran 7.0 Quick Reference
>> Guide
>>
>>
>> --
>> tsbernar
>> ------------------------------------------------------------------------
>> tsbernar's Profile:
>> http://bbsnotes.ugs.com/vbulletin/member.php?userid=191178
>> View this thread:
>> http://bbsnotes.ugs.com/vbulletin/showthread.php?t=41075
>>
>>

>
>

Re: AdvNL - Translation from NAstran to Adina input

Dear Chip and Tsbernar,
Thanks for your reply!
In the meantime I have found the reason for the very slow performance.
When working with SOL101 I use permanent constraints (and in the past also
with SOL601) to fix DOFs that are not connected to elements.
Now with NXNastran7.0 this causes the extrem slow creation of the
tmpadvnlin.dat file.
I have removed the permanent constraints on the nodes and the time for
creating the tmpadvnlin.dat file changes from 15 Minutes to just a few
seconds! (Model size ~200k Nodes)
This Problem was not present in NXNastran6.1! - Is there a new tranlation
process (adnast.exe) implemented in V7.0?
best regards
Wolfgang
PS: I have manually set the Solver Memory to 8192MB on a 64Bit XP Machine
with 16GB Physical RAM.
The max cached Label in FEMAP is set to 1e7
chip - I have posted this topic in the NXNastran Forum because I
thought that this is a solver problem. Is it possible to post a question in
two forums?

"tsbernar" wrote in message
news:tsbernar.44ung0@noreply.bbsnotes.ugs.com...
>
> Wolfgang,
>
> How much memory are you specifying for NX Nastran (mem keyword)? How
> much physical ram is installed on your machine? If you can provide
> output files (.log/.f04 and .f06), I can look into it further.
>
> BTW, you can specify memory for adina independently from NX Nastran
> using the NXNA_MEMORY environmental variable. See Remark 6 under "SOL
> 601,N or SOL 701" in Section 3.2 of the NX Nastran 7.0 Quick Reference
> Guide
>
>
> --
> tsbernar
> ------------------------------------------------------------------------
> tsbernar's Profile:
> http://bbsnotes.ugs.com/vbulletin/member.php?userid=191178
> View this thread: http://bbsnotes.ugs.com/vbulletin/showthread.php?t=41075
>
>

Wolfgang,

This definitely sounds like a bug. Please report it to GTAC so a PR can be opened and the problem corrected.

Regards,
--
Jim Bernard
Advanced Applications Engineer

Siemens PLM Software
2000 Eastman Dr., Milford, OH 45150-2712
www.siemens.com/plm

Re: AdvNL - Translation from NAstran to Adina input

Dear Wolfgang
In machines with more than 8 GB RAM is strongly recommend to use ILP-64 bit
NX Nastran solver. According manuals "NX Nastran executables are compiled
with a 64-bit integer size instead of 32-bits. The 32-bit integer executable
can allocate up to 8 Gb of memory, while the executable compiled with a
64-bit integer size can allocate approximately 20 million terabytes".
Best regards,
Blas.
--
~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
Edificio Ercilla
Rodríguez Arias 23, 3º - Dpto. 19
48011 BILBAO (SPAIN)
Tel. (+34) 94 410 65 50
Fax. (+34) 94 470 26 34
E-mail: info@iberisa.com
WEB: http://www.iberisa.com

>


Blas,

There is no such strong recommendation as to which executable to use based solely on the amount of installed memory.

A recommendation for the most efficient execution of NX Nastran on any platform is to only allocate as much memory as is required to keep the solution in core. Nastran is very IO intensive and the OS will use unallocated memory as IO cache. In general, the more unallocated memory available for IO caching the better.

With this in mind, the only time the ILP-64 executable is recommended over the LP-64 executable is if you are running a problem that requires a memory allocation of more than 8GB to keep the solution in core. If the solution does not require > 8GB to avoid spill, then the strong recommendation is to allocate less than 8GB to the solve and use the LP-64 executable.

The ILP-64 executable does come with a drawback in that integer word size is increased from 4 bytes to 8 bytes. This doubles the amount of IO required for integer storage. As IO is very typically the bottleneck in decreasing solution time, the extra IO does not help performance.
--
Jim Bernard
Advanced Applications Engineer

Siemens PLM Software
2000 Eastman Dr., Milford, OH 45150-2712
www.siemens.com/plm

Re: AdvNL - Translation from NAstran to Adina input

Dear Jim,
Thanks for commenting, I agree with you at all the experts. What end users should be know if they have installed NX Nastran 7.0 in a 64bit Windows OS & machine with say 16 GB RAM is that the new "ILP-64 is able to allocate more than 8 GB de RAM" and they can use the powerful NX NASTRAN Direct Sparse Solver to run very, very big models considered previously often the impossible, is unbelievable in solution speed, it is fine to use with smaller models, and in machines with more than 8 GB I should recommend it to be the "daily" solver.
According manuals there are 2 different 64-bit executable types available for NX Nastran 7.0:
a.. LP-64: 32-bit word size and 64-bit memory pointer size. Integers are 32-bits and floating point uses two 32-bit words.
b.. ILP-64: 64-bit word size and 64-bit memory pointer size. Integers are 64-bits and floating point uses one 64-bit word.
When LP-64 executable is used, the bytes_per_word is 4. When the ILP-64 executable is used, the bytes_per_word is 8. This difference is important when you are specifying memory with the "memory" keyword.
The LP-64 write *.op2 binary output files as 32-bit. However, the ILP-64 produces a different binary file format since all integers and floating point data are written out with a 64-bit precision. Depending on the use of the binary output files from a 64-bit machine, you may need to convert a 64-bit files's format back to 32-bit. For example, post-processors currently only support 32-bit integers, thus the need to convert .op2 files to 32-bit.
The ILP-64 executables have the following limitations:
a.. You only convert those data blocks that are NDDL defined from 64-bit to 32-bit. See chapter 3 of the NX Nastran DMAP Programmer's Guide for more information on NDDL.
b.. All .op2 binary files written during a solution are in one precision format, that is, they are all either 32-bit or 64-bit precision .op2 files.
c.. The INPUT2 files are not converted.
Best regards,
Blas.
--
~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
Edificio Ercilla
Rodríguez Arias 23, 3º - Dpto. 19
48011 BILBAO (SPAIN)
Tel. (+34) 94 410 65 50
Fax. (+34) 94 470 26 34
E-mail: info@iberisa.com
WEB: http://www.iberisa.com
"tsbernar" escribió en el mensaje de noticias news:tsbernar.44wqob@noreply.bbsnotes.ugs.com...
>
> Blas Molero Hidalgo;178868 Wrote:
>> Dear Wolfgang
>> In machines with more than 8 GB RAM is strongly recommend to use ILP-64
>> bit
>> NX Nastran solver. According manuals "NX Nastran executables are
>> compiled
>> with a 64-bit integer size instead of 32-bits. The 32-bit integer
>> executable
>> can allocate up to 8 Gb of memory, while the executable compiled with a
>> 64-bit integer size can allocate approximately 20 million terabytes".
>> Best regards,
>> Blas.
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~
>> Blas Molero Hidalgo
>> Ingeniero Industrial
>> Director
>>
>> IBERISA
>> Edificio Ercilla
>> Rodríguez Arias 23, 3º - Dpto. 19
>> 48011 BILBAO (SPAIN)
>> Tel. (+34) 94 410 65 50
>> Fax. (+34) 94 470 26 34
>> E-mail: info@iberisa.com
>> WEB: http://www.iberisa.com
>>
>> >

>
> Blas,
>
> There is no such strong recommendation as to which executable to use
> based solely on the amount of installed memory.
>
> A recommendation for the most efficient execution of NX Nastran on any
> platform is to only allocate as much memory as is required to keep the
> solution in core. Nastran is very IO intensive and the OS will use
> unallocated memory as IO cache. In general, the more unallocated memory
> available for IO caching the better.
>
> With this in mind, the only time the ILP-64 executable is recommended
> over the LP-64 executable is if you are running a problem that requires
> a memory allocation of more than 8GB to keep the solution in core. If
> the solution does not require > 8GB to avoid spill, then the strong
> recommendation is to allocate less than 8GB to the solve and use the
> LP-64 executable.
>
> The ILP-64 executable does come with a drawback in that integer word
> size is increased from 4 bytes to 8 bytes. This doubles the amount of IO
> required for integer storage. As IO is very typically the bottleneck in
> decreasing solution time, the extra IO does not help performance.
>
>
> --
> tsbernar
>
> ::--::
> ::Jim Bernard::
> ::Advanced Applications Engineer::
>
> :Smiley Frustratediemens PLM Software::
> ::2000 Eastman Dr., Milford, OH 45150-2712::
> ::www.siemens.com/plm::
> ------------------------------------------------------------------------
> tsbernar's Profile: http://bbsnotes.ugs.com/vbulletin/member.php?userid=191178
> View this thread: http://bbsnotes.ugs.com/vbulletin/showthread.php?t=41075
>

Re: AdvNL - Translation from NAstran to Adina input

Dear Jim,
Thanks for commenting, I agree with you at all the experts. What end users should be know if they have installed NX Nastran 7.0 in a 64bit Windows OS & machine with say 16 GB RAM is that the new "ILP-64 is able to allocate more than 8 GB de RAM" and they can use the powerful NX NASTRAN Direct Sparse Solver to run very, very big models considered previously often the impossible, is unbelievable in solution speed, it is fine to use with smaller models, and in machines with more than 8 GB I should recommend it to be the "daily" solver.

According manuals there are 2 different 64-bit executable types available for NX Nastran 7.0:
a.. LP-64: 32-bit word size and 64-bit memory pointer size. Integers are 32-bits and floating point uses two 32-bit words.
b.. ILP-64: 64-bit word size and 64-bit memory pointer size. Integers are 64-bits and floating point uses one 64-bit word.
When LP-64 executable is used, the bytes_per_word is 4. When the ILP-64 executable is used, the bytes_per_word is 8. This difference is important when you are specifying memory with the "memory" keyword.
The LP-64 write *.op2 binary output files as 32-bit. However, the ILP-64 produces a different binary file format since all integers and floating point data are written out with a 64-bit precision. Depending on the use of the binary output files from a 64-bit machine, you may need to convert a 64-bit files's format back to 32-bit. For example, post-processors currently only support 32-bit integers, thus the need to convert .op2 files to 32-bit.

The ILP-64 executables have the following limitations:

a.. You only convert those data blocks that are NDDL defined from 64-bit to 32-bit. See chapter 3 of the NX Nastran DMAP Programmer's Guide for more information on NDDL.
b.. All .op2 binary files written during a solution are in one precision format, that is, they are all either 32-bit or 64-bit precision .op2 files.
c.. The INPUT2 files are not converted.
Best regards,
Blas.
--
~~~~~~~~~~~~~~~~~~~~~~
Blas Molero Hidalgo
Ingeniero Industrial
Director

IBERISA
Edificio Ercilla
Rodríguez Arias 23, 3º - Dpto. 19
48011 BILBAO (SPAIN)
Tel. (+34) 94 410 65 50
Fax. (+34) 94 470 26 34
E-mail: info@iberisa.com
WEB: http://www.iberisa.com
>



Blas,

Yes, the information you've copied from the manuals is correct.

One additional note regarding your point about binary format conversion. The conversion is controlled by system cells 413 (OP2FMT), 415(OP4FMT) and 416(INP4FMT). The default for OP2FMT is to always convert 64 bit binary to 32 bit binary if PARAM, POST >0 is specified. So, if PARAM, POST -1 or -2 is specified, the user does not have to do anything. The results .op2 will be readable by current post processors.
--
Jim Bernard
Advanced Applications Engineer

Siemens PLM Software
2000 Eastman Dr., Milford, OH 45150-2712
www.siemens.com/plm