Yet, also consider this. It is not entirely random. Runs which once worked , always work, Runs which once crashed with the 157 error always crash even at the same point (it seems to me at least) into the execution... as if "something" fills up and then overflows.
Joachim Mark Sale - Next Level Solutions <[EMAIL PROTECTED]> 07.12.2007 14:44 To [EMAIL PROTECTED] cc nmusers@globomaxnm.com Subject RE: [NMusers] error (157) forrtl: severe Interesting, The only thing I can think of that would be random like that is that some other program (virus checker? back up?) is accessing the files. Maybe the slower ADVANS don't mind because they access the file(s) less often, and haven't happened to try when the other program is accessing them. Mark Mark Sale MD Next Level Solutions, LLC www.NextLevelSolns.com 919-846-9185 -------- Original Message -------- Subject: RE: [NMusers] error (157) forrtl: severe From: [EMAIL PROTECTED] Date: Fri, December 07, 2007 7:56 am To: [EMAIL PROTECTED] Cc: nmusers@globomaxnm.com Thank you, Mark for responding. Yes, NONMEM is running often just fine - up to a few hundred function evaluations. But sometimes it crashes even before I see the first iteration. When it crashes later I see the entire set of FILEs and executables in the directory. So NONMEM and NMTRAN were working fine. But, how do you explain that the same models reformulated with ANDAN6 run? Well, they take very long... and none of them has run to a successful minimization yet. Joachim Mark Sale - Next Level Solutions <[EMAIL PROTECTED]> 07.12.2007 13:44 To [EMAIL PROTECTED] cc nmusers@globomaxnm.com Subject RE: [NMusers] error (157) forrtl: severe Joachim, This is probably a file access error, from Fortan/OS, not from NONMEM. Does NMTRAN run? Does the compiler run? Does nmlink6 run (do you get link.lnk)? Do you get an executable? Does NONMEM start then stop? If you get the executable (nonmem.exe or fsubs.exe), then the error is with file access in the NONMEM itself. Don't know which file, but if NMTRAN runs it isn't the (NMTRAN) data set, still could be FDATA, FCON, FSTREAM, FRECORD, any of the FILE? (but probably not) or an MSF. Fortran should close all the files when it exits, by any method (e.g., if it crashes). Could conceivable be a library file from the compiler as well. Mark Mark Sale MD Next Level Solutions, LLC www.NextLevelSolns.com 919-846-9185 -------- Original Message -------- Subject: [NMusers] error (157) forrtl: severe From: [EMAIL PROTECTED] Date: Fri, December 07, 2007 6:19 am To: nmusers@globomaxnm.com A question for FORTRAN experts: Fortran Error 157: access violation is the error we see when NONMEM crashes on our server installation with models which otherwise run fine on our local PC installations of NONMEM. These crashes occur with very simple (ADVAN2) and also with rather complicated (ADVAN5, ADVAN7) models. They can be avoided when models are reformulated with ADVAN6 TOL=5. Of course with ADVAN6 all models run slower and this is not really a solution of our problem. We run NONMEM VI without the recent bug fixes in a "naked" fashion on the server, and with "wings" on the PCs. Our compiler is Compaq Visual Fortran (latest version). We appreciate your thoughts on that. __________________________________________ Joachim GREVEL, Ph.D. MERCK SERONO International S.A. Exploratory Medicine 1202 Geneva Tel: +41.22.414.4751 Fax: +41.22.414.3059 Email: [EMAIL PROTECTED] This message and any attachment are confidential, may be privileged or otherwise protected from disclosure and are intended only for use by the addressee(s) named herein. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck Serono does not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. If verification is required, please request a hard-copy version. Merck Serono does not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith.
