Jump to content
GMS, SMS, and WMS User Forum

Nate

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Nate

  • Rank
    Member

Profile Information

  • Location
    Cape Cod
  1. We got version ADCIRC version 47.20 with SMS 10.0.6. According to the most recent ADCIRC documentation at www.adcirc.org this version has the tau0 = -3/-4 options for automatic Tau0 assignment. however these options require the specification of Tau0FullDomainMIN and Tau0FullDomainMax on the line following Tau0 in the fort.15 file. when I try to specify tau0 = -3 or -4 and include Tau0FullDomainMIN and Tau0FullDomainMax on the following line, SMS 10.0.6 will not read my fort.15 file. If I leave out Tau0FullDomainMIN and Tau0FullDomainMax from the fort.15 (using -3 or -4 for tau0) ADCIRC crashes upon reading the fort.15. I can get the Tao0 = -3/-4 options to work with SMS if I first load the fort.15 file without the Tau0FullDomainMIN and Tau0FullDomainMax line, then edit my fort.15 to include the Tau0FullDomainMIN and Tau0FullDomainMax line, then run ADCIRC. It's not too much trouble but I think it should be addressed. SMS needs to provide users the ability specify Tau0FullDomainMIN and Tau0FullDomainMax from within the SMS ADCIRC interface. also, If I try to run ADCIRC after loading my fort.14 but before loading my fort.15 SMS trashes my fort.15 file . Good thing I made a copy of it before trying that one. Have a nice day, Nate
  2. Hi John, I sent an example set of files to support@aquaveo.com for you. Here's what I did to cause the problem: 1) I open the fort.14 with SMS 10.0.6 (using: File | open) 2) switch to geographic coordinates because SMS 10.0.6 tells me to and won't open the fort.15 until I do so. (this shouldn't be necessary, the fort.15 file for ADCIRC has an ICS variable to tell it if it should use spherical(geographic) coordinates or Cartesian coordinates, couldn't SMS just read this and automatically change to the correct coordinate system). open fort.15. 3) run ADCIRC 4) after ADCIRC has written a few records to the fort.63 and fort.64 hit the "Abort" button 5) try to open the fort.63 or fort.64 Thanks, Nate
  3. the top of my files look like this: " DATASET OBJTYPE mesh2d BEGSCL OBJID 1 ND 79795 NC 76330 NAME "wse" TS 1 0.20000000E+02 1 1 1 " the "wse" dataset may or may not be followed by additional vector and/or scalar datasets for velocity, salinity, etc... note the OBJID card on line 4. this card is shown in the examples in the wiki and in the SMS9.0 help, however there is no description of the card's format. my code which generates the .dat files puts this line there because that's what I saw in the examples. I've found that If I remove the OBJID card on line 4 SMS 10.0.6 will read the file and I can see the data, but I still get an error(very similar to what I was getting before) that says: "Error: ND card before object was defined (line 3590910)" -there's another OBJID card on line 3590909 of my file for the next data set. I guess these OBJID cards are the problem. I'll have to modify my code to stop writing these cards. What are they used for anyway? SMS9.0 doesn't seem to care if the OBJID cards are there or not(at least for my application) thanks for the quick response, -Nate
  4. Has the format for the generic ascii data files and/or 2d mesh files changed since SMS 9.0? I have a number of fortran codes and matlab scripts etc. which I use to read and produce files in SMS's generic *.2dm and *.dat (ascii) formats so that I can view and edit data for non-SMS hydrodynamic models (such as EFDC). however since I upgraded to 10.0.6 today SMS will not read my *.dat files which contain both scalar and vector data. when I try to open a *.dat file after opening my *.2dm mesh I get an error that says: "Error: ND card before object was defined (line5)" I don't know what this means my *.dat files don't have any ND cards, the ND cards are in my *.2dm file. I am able to open my *.2dm files, however I get a message that says: "Some material properties values were missing. They will be defaulted for the model to run correctly." I cannot find any information on the format of these files (*.2dm and *.dat) in the SMS 10.0.6 online help like what I was able to find in the SMS 9.0 and 8.1 offline help. anyone else use these generic ascii files? are you having the same problem? Thanks, Nate
  5. Opps. My bad, I'll post it in the SMS forum instead.
  6. Has the format for the generic ascii data files and/or 2d mesh files changed since SMS 9.0? I have a number of fortran codes and matlab scripts etc. which I use to read and produce files in SMS's generic *.2dm and *.dat (ascii) formats so that I can view and edit data for non-SMS hydrodynamic models (such as EFDC). however since I upgraded to 10.0.6 today SMS will not read my *.dat files which contain both scalar and vector data. when I try to open a *.dat file after opening my *.2dm mesh I get an error that says: "Error: ND card before object was defined (line5)" I don't know what this means my *.dat files don't have any ND cards, the ND cards are in my *.2dm file. I am able to open my *.2dm files, however I get a message that says: "Some material properties values were missing. They will be defaulted for the model to run correctly." I cannot find any information on the format of these files (*.2dm and *.dat) in the SMS 10.0.6 online help like what I was able to find in the SMS 9.0 and 8.1 offline help. anyone else use these generic ascii files? are you having the same problem? Thanks, Nate
  7. Hello, I'm not sure if this is the best place to post an SMS bug, if not, what is? anyway, here it is: I just started using SMS 10.0.6 today for some ADCIRC modeling. I've found that SMS 10.0.6 cannot read a fort.63 (or fort.64) file from an ADCIRC simulation that crashed before it's written all the global output it expected to. I get an error that says "failed to load correctly" I believe SMS 10.0.6 is trying to read past the end-of-file. This is probably because it reads NDSETSE (the first integer on line 2 in the fort.63) and expects to find more records than are actually in the file (note: NDSETSE is calculated and written to fort.63 at the beginning of the run before the run knows it's gonna crash. therefore if the run crashes before TOUTFGE, NDSETSE is wrong!). I can trick SMS 10.0.6 into reading the file by changing the NDSETSE value to something less than or equal to the actual number of records in the file. However, this is not a trival task with a large fort.63/64 I find it extremely important to be able to visualize output from hydrodynamic simulations that have crashed because it helps me figure out what is causing the crash and how to fix it. this should be an easy fix. I never had this problem using SMS8.1 or SMS9.0 and I've had lots of ADCIRC runs crash. Thanks, Nate
×
×
  • Create New...