I have a large model (2M dof) on my C-drive. I want it to stay there, but there's not much space left.
I'm running a SOL103 and so I've sent the output files (including the scratch files) to the D-drive, which has more space than you can shake a stick at.
However, I keep getting the following error saying that the SCR300 is still being written to the C-drive, which is running out of space!
Does anyone know how to redirect this SCR300 to the D-drive?
Thanks very much.
Running NASTRAN 12 on Simcenter 12.
Output file directory set using 'Advanced Solver Options'
Scratch files created in 'Solver Parameters' and setting the scratch file directory using 'sdirectory'.
I also tried not writing scratch files and allowing the dball (still the scr300 error)
The op2 file is always written to exactly the same size (808,077 KB)
*** USER FATAL MESSAGE 1250 (BIOWRT)
STATUS = 112, FILX = 5, LOGNAME = SCR300 , NSBUF3 = 32768
FILE = c:/users/.../temp/srs_-_tup_container_-_hif_isolation_mounting_stp_assyfem1_sim1-solution_2a.T11320_0.SCR300
BLKNBR = 225740
ERROR MESSAGE IS --
There is not enough space on the disk.
BIOMSG: ERROR 923 HAS OCCURRED IN ROUTINE IONAST , FILE INDEX = 5.
LOGICAL NAME IS SCR300
FILENAME IS c:/users/.../temp/srs_-_tup_container_-_hif_isolation_mounting_stp_assyfem1_sim1-solution_2a.T11320_0.SCR300
STATUS = 112
*** SYSTEM FATAL MESSAGE 4276 (IONAST)
ERROR CODE 923 PID= 0
USER INFORMATION: THIS ERROR MAY BE CAUSED BY EXCEEDING THE CAPACITY OF A SYSTEM RESOURCE.
(E.G., ALLOCATED DISK IS FULL, OR MAXIMUM FILE SIZE HAS BEEN REACHED)
*** USER INFORMATION MESSAGE 4276 (IONAST)
TO OBTAIN A NASTRAN DUMP RESUBMIT JOB WITH DIAG 44 INSERTED IN THE EXECUTIVE CONTROL SECTION.
1 * * * END OF JOB * * *
check the ASSIGN keyword
in the old day long file path (with space) and long nme was ano-no. Nor sure now days
What can't you move your .dat/.bdf file(s) on the D drive and run the analysis from there?
You indicated that you already tried setting sdirectory and that is not working.
Can you post a copy of your .log, .f04 and .f06 file to this thread?
I attempted to attach the files, but was given the following error:
"The contents of the attachment doesn't match its file type."
As such, I've sent them directly to you as a private message.
The .log file shows the following:
SDIR='c:/users/user/appdata/local/temp/srs_-_tup_container_-_hif_isolation_mounting_stp_assyfem1_sim1-solution_2a.T11320_0' Command Line: D:\a_simcenter_projects\2018.2108 - HIFHS SRS\101\srs_-_tup_container_-_hif_isolation_mounting_stp_assyfem1_sim1-solution_2a.dat prog=bundle old=no memory=40GB scratch=no sys442=2 parallel=20
So, SDIR is set to a location on C: and SDIR is not being specified on the command line.
If you specify SDIR on the command line and set it to a location on D:, then the scratch files should be written to D: rather than C:.
For future reference, to post files with unrecognized extensions, you can rename them to .txt (for ascii files) or zip them up and post the .zip file.
Thanks for your investigation, in which you determined that the scratch files were indeed still being sent to the C-drive.
In the attached picture (sdirectory1.gif), you can see how the D-drive is now selected within Simcenter 'Solver Parameters'. In the run that I previously refered to, the text shown (and outlined in red) wasn't showing, although I had certainly selected it in the browser. Following your last post, I played around with it a bit and somehow was able to get teh text to show up in the box (I was trying different things, so can't recall which one worked).
With the text showing in the box, it made a difference. However, the job only ran as far as writing the deck, then stopped.
It may be the old problem of having spaces in the filename/path, or the filename/path being too long.
Instead, I removed the text from the box and edited the .rcf file as proposed by Karachun - this gave me success (all files except SSS.MASTERA and SSS.MSCOBJ going to D-drive).
Perhaps the sdirectory box issue is something that Siemens could look at and advise on?
In the meantime - thanks for your help.
See disk_usage1.gif attached - I still seem to have a genuine problem with disk space, as it appears to be overloading the 1TB D-drive too!