Initial Child OS X Test

I've compiled the Child code under OS X and g++ 4.0.1, and have run it using inputs derived from the Child_inputs files. Specifically, what I've done is:

  1. Created an OS X test directory with subdirs Input and Output.

  2. Copied the test_P4_mb1_nb1_1 files ending in .in, .random, .nodes, .edges, .tri, and .z to the Input dir.

  3. Renamed these files test.whatever.

  4. Edited test.in so that OUTFILENAME = Outputs/test, INPUTDATAFILE = Inputs/test, and RUNTIME = 10000.

  5. Changed the first timestamp in every other file from 0 to 3000000. Although these were output files from a previous run, the first timestamp was 0 in each (presumably a bug), while the others were 3005000 and 3010000. Leaving the first timestamp at 0 caused the second data segment (rather than the first) to be used for mesh initialization, which results in many many errors (e.g. all non-CCW triangles).

  6. Removed all data beyond time = 3000000 in each input file.

The program was run with something like: 

10: ~/Projects/Lancaster/Child/Child_CU_STL_2006/OSX_test > date ; ChildOSX Inputs/test.in >& run.log ; date
Sun Feb 10 13:36:18 PST 2008
Sun Feb 10 13:54:42 PST 2008

The 10000 year run (at 10 year steps) took 18.4 minutes. If the results are linear, then the full 300000 year run should take about 9.2 hours.

Question: Are these figures consistent with your experience?

All files (inputs, outputs, run log) are available for download here.

The run log was compared to test_P4_mb1_nb1_1.out:

These files are almost exactly the same, with a few differences (some non-CCW triangles in one or the other (?), and differences in numerical values at the last decimal place) up to time = 3.00063e6:

and then they begin to diverge:

See the two log files in the archive for how much they diverge at time = 3.01e6.

Question: Why do the two log files look identical for 62 iterations, and then begin to diverge? I can think of two possible explanations:

  1. The two pseudorandom sequences are different?
  2. Your simulation is chaotic, and small differences in the numbers (at the last decimal place) eventually create a bifurcation in the mesh? This may not be a problem, but we need to know that it isn't (see additional comments below). That is, we need to verify that two different meshes which represent the same topography will produce the same results (i.e. that the results are robust wrt perturbations in the mesh).

In this case, the output of the .z files are nearly identical:

although there are different numbers of nodes at each time step, and the values differ by a few decimal places:

Question: Does this make a difference? i.e. Are these results really the same?

The other files I've looked at (e.g. .nodes) show similar results: mostly the same in most places, but slightly different elsewhere.

Question: Although I can figure this out myself, it would save some time if you could provide me with a brief description of each of these (input and output) files, and the format (layout) of data in each.

Question: Do you have data for other example runs I can try? In particular, I would like to try an example where OPTREADINPUT = 2 --that is, where the input is a set of (x, y, z) coords and the program has to generate a new mesh from these. The current example tested used a previously generated mesh, which may be suspect.

For work in the near future, three things seem clear:

  1. I am currently running blind. I need to get some graphics going ASAP. Probably not GL surface shading yet, but just simple wireframe lines of the topography grid, and a way to see and compare two grids at the same time. This will probably be my next task.

  2. I need a way to compare results independently of the underlying mesh and triangulation. Although the non-uniform grid triangulation method has advantages, it also has disadvantages, specifically that a given topography can be gridded/triangulated in many different ways. I need a way to see the differences between topographies independently of their meshes, and to verify that they are the same, and the results are the same, even if the meshes are different. This might involve some kind of discrete piecewise, continuous, or parametric (e.g. splines) comparison.

  3. For this project, I need to concentrate on the river banks. This means highlighting the river nodes and triangulation separately from the rest of the topography, and tracking their changes in preference to other changes to the geometry (and independently of the underlying mesh as in (2) above).

    Question: Do you really know that the topography (especially the 'far field' topography) has any significant effect on the river meandering? I've looked at tStreamMeander.cpp and meander.f and meander.cpp, and am looking for some way to make the JP model 'plug compatible' without disturbing the rest of the code, but... Do you know that the rest of the topography couldn't be replaced by (for example) a flat unchanging plane (without pools), without significantly affecting the river meandering geometry?

© Sky Coyote 2008.