This past week or so saw some more errors in MARSSIM output, but it seems to have culminated in what appears to be a successful “run.”

Since the problem with the Frank Crater run lay ultimately with the way that QGIS converted (improperly) the original DTM (Digital Terrain Model; a 2d rendering of a plot of land) into the ASCII file that MARSSIM could work with, the next step was to try the same conversion process using ArcGIS and see if that turned out any better.  For this, resident Post-Doc, Mike, gave me input data pertaining to Meteor Crater, Arizona.

The run of the first ‘inelev.dat’ file for Meteor Crater gave the following:

outelev-01000-dat-cub-2
Meteor Crater…, sort-of.

Basically, what happened here was the result of a “loss in translation” between ArcGIS and MARSSIM:  While MARSSIM “reads” data from DTM’s the way a Westerner would read a book, ArcGIS does not (it “reads” starting from the bottom of a DTM, for some reason).  As a result, MARSSIM spat out more bad results (see Dr. Tornabene, previous post).

With further tinkering of the DTM conversion done by Mike, an ‘inelev.dat’ file was soon obtained that produced this more amiable .gif output:

crater_movie01
It’s a crater!  Now to fix the crappy-looking erosion….

The result, above, could still be more “ideal,” but at least it looks like it should.  That run was done over 1,000 iterations; the gif below was done over 10,000:

crater_movie_long
Crappy erosion fixed!  Sort-of….

It appears an eroding crater from initial DTM data has finally been achieved.  The alternating white-and-black boxes that slowly encroach on the crater through the gif’s duration is due to the presence of a border in the original ArcGIS DTM of Meteor Crater (which gave a number of zeroes in the ‘inelev.dat’ file).  Barring that, everything else appears fine.

Problem solved?  I guess I’ll find out when I apply the same procedure to Frank….