Jump to content
GMS, SMS, and WMS User Forum

Mark Prater

  • Content Count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About Mark Prater

  • Rank
    Senior Member

Profile Information

  • Location
    Rhode Island
  1. I can now generate a hemisphere-spanning mesh by performing the coordinate projections and re-projections external to SMS, and use SMS only for the mesh generation. Within SMS I set my projection to "Local projection" with the units set to "Meters". I'm still curious if there are better ways to do this entirely within SMS.
  2. One additional note: I thought I would be clever, so I shifted all the longitudes in my *.cst and .pts files to be centered around the zero meridian rather than around 180E. That seemed to solve my initial problems, and I was able to generate a mesh. However, I got the same "Encountered an improper argument" when attempting to re-project from the UTM zone back to geographic coordinates. Also, I played with the USGS version of Global Mapper to see how it deals with crossing hemispheres at 180E. If I load my *cst file with all positive longitudes, I see a "Coordinate out of range" message for points greater than 180,. Likewise, if I load my *cst file with all negative coordinates, I see a "Coordinate out of range" message for points less than -180. So, the Global Mapper utility is also bothered by crossing the 180 meridian. Cheers, -- Mark
  3. I forgot to mention that I'm using SMS 10.1.11 (build Jan 24, 2011)
  4. I am trying to develop a mesh that spans the eastern and western hemispheres at 180E, and I am (or SMS is) having some difficulty with the input coordinates. I've played with several test domains to understand my problem, and have found out that ( test 1) I can easily create a mesh when the domain is entirely in the western hemisphere, and my *.cst and *.pts file longitudes are specified in negative degrees east (that is, Seattle, USA is -122.33E). (test 2) I can easily create a mesh when the domain is entirely in the eastern hemisphere, and my *.cst and *.pts file longitudes are specified in positive degrees east (that is, Tokyo, Japan is 139.69E). (test 3) I have not been able to create a mesh when the domain is entirely in the western hemisphere, and my *.cst and *.pts file longitudes are specified in positive degrees east (that is, Seattle, WA is 237.67E). I can load my *.cst file without problem, but when I "Select Feature Arc" and click on my domain boundary I get an error message that states "Encountered an improper argument." Any attempt to re-project the data to a UTM zone produces the same error message, and the data is not re-projected (test 4) When I attempt a cross-hemisphere domain with my *.cst and *.pts file longitudes specified in positive degrees east, I get the same failures as in test (3). (test 5) When I attempt a cross-hemisphere domain with my *.cst and *.pts file longitudes specified in negative degrees east, I get the same failures as in test (3). So, my specific questions are (1) Can I use Geographic coordinates in my *.cst and *.pts files for a domain that spans hemispheres at 180E? If yes, how? If not, what coordinate system do you suggest? (2) What re-projection Cartesian coordinate system do you recommend for smoothing data sets and for the actual mesh generation (Map -> 2-D Mesh)? Thanks!
  5. Thanks John. My *cst file problem was a bit of a pebkac - I forgot to set my default model preference to ADCIRC. Once I did that, all my favorite options reappeared in the pull-down menus. Hopefully I'll have no (intelligent) reason to revisit v10.0. Cheers, -- Mark
  6. Hi, Once I got my password for SMS v10.1 and "burned" my hardware lock, I discovered that I could no long use SMS v10.0 except in demo mode. I've asked about this, and have been told that I would be issued a "temporary password" for v10.0. I guess my question is: I understand that I'm limited to use the software on the machine with the hardware lock, but why am I limited to which version of software that I use? Thanks, -- Mark (I'm especially interested in this because v10.1 is not letting me set the attributes to feature arcs that I loaded from a *.cst file. If that problem persists I'll spawn a separate post for it.)
  7. Hi John, Thanks for the suggestion. I've just sent a message off to Tech Support. Cheers, -- Mark
  8. Good afternoon, I have a *.tif image that I'm using as a SMS background while I'm developing an ADCIRC mesh. The image was originally unreferenced, and I geo-referenced it to NAD83 via the "Register Image" option. I then loaded in my lat/lon *.cst file, and the CST data and the image line up very nicely. So, I'm assuming I did all that correctly... After creating an ocean boundary, I then transformed my project coordinates to UTM NAD83 (zone 18), and the image and CST data seem to transform differently. The CST data skews to the left, while the image skews to the right, although the two still overlap. Based on previous experience, I'm guessing that the CST transformed correctly, while the image did not. I took snapshots of the SMS screen before and after transformation, and uploaded them in the file "mdp_conversion_problem.jpg" (83Kb) to demonstrate the issue. Do you have any suggestions? Thanks, -- Mark
  9. An additional bit of information - the error seems to occur only when I also choose the "Truncate values" option within the "Scatter Options..." window. That is another option I probably don't need since my mesh size scatter set has already has its minimums and maximums set to my specified limits. -- Mark
  10. I'm using SMS (10.0.11) to generate 2-D meshes, using the Scalar Paving Density option. I select the "Scatter Options..." to select my scatter set, and set my interpolation options. I would like to select the Extrapolation option "Inverse Distance Weighted", and I alway get the error "The current single value extrapolation value is less than the minimum truncation value entered. The single value extrapolation value will be set equal to the minimum truncation value entered." So, I'm not sure if my request for Inverse Distance Weighted was ignored, or is not available for the Scalar Paving Density option. I try to make sure that extrapolation is not needed by creating a buffer zone in my scatter set around the boundary of my computational domain, but still it would be nice insurance to have. Thanks... Mark
  11. Thanks John, for your suggestion. The buffer polygon idea seems obvious now that you've said it! I'll give it a try. Cheers, -- Mark
  12. I would also support this idea. I'd really like to be able to run my more repetitive SMS grid developments from a script rather than pointing and clicking through the same menu options. Maybe for version 11? -- Mark
  13. I have been using "scalar paving density" to develop my meshes, using a scatter point file constructed outside of SMS that contains my "ideal" meshsize distribution throughout the domain. That has worked very well up until now. I am now incorporating island barriers, and have a *.cst formatted file with the barrier points. I can construct my barrier points to match up on opposite sides of the barrier, but if I use the scalar paving density method to construct my mesh, the barrier points (nodes) have all shifted, and I no longer have a one-to-one coorespondance of nodes on either side of the barrier. My initial question is: can I use the scalar paving method AND keep specified points fixed (like along my barriers)? If not, then how to I reconcile this two, possibily incompatible, goals? Thanks! -- Mark
  14. I have several inane questions about specifying weirs using SMS (my current version is 10.0.6). * Is a "weir" in SMS the same as an "interior barrier boundary" in ADCIRC? * How to I create an ADCIRC weir? I could not find any information in the xmswiki pages. My attempts to create a pair of closely aligned feature arcs, distributing equal numbers of vertices in each, and trying to assign the "weir" attribute have all resulted in the error message "Weirs can only be created between two nodestrings with equal number of nodes. 2118386775 nodestrings selected." So, I gather that my approach is incorrect. Thanks in advance for any suggestions. -- Mark
  15. Hi all, I'm trying to load a spatial attribute file (fort.13) into SMS (v10.0.3), but SMS does not offer a "file type" for fort.13, athough one for fort.21 (friction) is included. The xmswiki described how to implement the attributes after they've been read in, but how do I read in the fort.13 file? Thanks -- Mark
  • Create New...