Mike, thanks for the message. First of all, it didn't reach the list because I closed it off for non-subscribers -- too much spam has hit gstat-info recently. I'll attach it below. The %g is used so often because it gives, at least in my opinion the best human-readable output. You're right that the code writing simulations to ascii files should use the user-supplied format specification, and not use the %g format. If you can send me the corrected code, I will put it on the web. I can't follow you where you state that you have to set nsim to 2 (or larger) in order to get SGS. I thought gstat would simulate a single value if you omit it. -- Edzer
>From [EMAIL PROTECTED] Mon Jul 23 17:18:08 2001 Received: from Apollo.syrres.com (apollo.syrres.com [204.168.121.242]) by pop.geog.uu.nl (8.8.8/8.8.8) with ESMTP id RAA10591 for <[EMAIL PROTECTED]>; Mon, 23 Jul 2001 17:18:05 +0200 (METDST) From: "Mike Dearman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Sequential Gaussian Simulation & Ascii EAS Output problems Date: Mon, 23 Jul 2001 11:16:45 -0400 Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I am trying to perform a sequential gaussian simulation with gstat 2.3.0 (dec. 1st 2000 build). I use asciigrid (eas) files for input with a command file shown below. I noticed that another message on the list from Pierre Gagnon, entitled "Sequential gaussian simulation", talked about the same problem, yet I don't think anything was solved directly. I cannot implement the same methods as he used to work around the problem. # # Gaussian simulation, conditional upon weighted normal score - transf data # (local neighbourhoods, simple and ordinary kriging) # data(lead): 'NewWeightedSite4ns.dat', x=2, y=3, v=7, sk_mean=0, max=8, radius=200; variogram(lead): 0.1 Nug(0) + 0.9 Exp(233); data(): 'sitelocs.eas', x=1, y=2; #delineates the irregular block for Gstat. set output = 'testSim.est'; #GEO-EAS output file method: gs; set nsim=2; set zero=1.0e-10; set debug=395; # looots of debug info set format='%20.12f' Here is what I found: I noticed that when I have an "nsim" value above 1 (ie: gstat really does perform a SGS computation), then my output EST File does not follow my specified formatting option. I looked into this more, as my X,Y values were losing too much precision to be able to reverse-lookup their original values. I found the source code for what appears to be gstat 2.3.3. I traced thru by hand the execution of the simulation, and found that in the "msim.c" module, in the function "save_simulations_to_ascii(const char *fname)", it appears as though gstat isn't using the global variable "gl_format" which comes from the "set format" option. It is using the %g printf format specifier (which only uses 6 significant figures by default). This is in the code that prints the non-stratisfied/stratisfied x,y,z coordinates and estimated simulation values. Here is the code fragment from that function (I hope its ok to post here) ... if (d[0]->mode & X_BIT_SET) fprintf(f, " %g", d[0]->list[s2d[0][i]]->x); if (d[0]->mode & Y_BIT_SET) fprintf(f, " %g", d[0]->list[s2d[0][i]]->y); if (d[0]->mode & Z_BIT_SET) fprintf(f, " %g", d[0]->list[s2d[0][i]]->z); for (j = 0; j < n_vars; j++) for (k = 0; k < gl_nsim; k++) fprintf(f, " %g", msim[j][i][k]); ... I'm pretty sure this is an oversight in code, but I am wondering why the default for most of the floating point variables is %g. It seems like 6 total sig figures (including whole number and fractional part) isn't very precise. Yet, %f has a 6 sig fig default only for the fractional part (ie: only fractional part is rounded off). Which seems like the better choice. I can only see one advantage for using %g, that being that you can always guarantee that the number field (column) would be about (6 digits + sign + decimal point) characters wide (plus any padding from field wide specifier) Instead of trying to setup my compiler and the libraries, I just hex edited the gstat executable and replaced all %g strings with %f, which allowed me to work around the problem temporarily, but I would like to submit for correction the error in code for future versions, as I'm sure anyone working with simulations is going to run across this problem. Also, if the change is made to the source, when is the next planned release of gstat that would incorporate this change? I'm looking to release this software package (that uses gstat) and would like to have an official release version. Thanks in advance, Mike =============================== Mike Dearman Systems Technology Center Syracuse Research Corporation - www.syrres.com
