viewing a SA from the command line ("sadump")

Question

viewing a SA from the command line ("sadump")

teuben opened this issue 6 months ago · 6 comments

For data in HDF5 or netCDF format we have useful command line tools like h5dump and ncdump. For NEMO we have the "tsf" program to just view what's inside this binary blob. For text files we have "more" :-) But for a SA there is nothing yet?

It's possible I might do this myself, but don't pin me on it yet. I would suggest the name sadump, but perhaps you have a naming preference with reb_ ?

Answer 1 · 2024-07-08T18:56:58.000Z

Probably my reb2s program in NEMO can be a good base to test out the idea, but in reb2s it might have issues with snapshots where particles appear and disappear, i.e. where the number of bodies changes. I need an example SA for this.

Answer 2 · 2024-07-08T19:51:00.000Z

I think it's quite tricky. What do you think the sadump program should output? It can't just dump the particle positions. For integrators that use symplectic correctors, for example, it might need to perform a synchronization step. For cases where additional forces have been added, it would also need to know how to find the relevant function pointers. It could output something about the number of snapshots and the start/end times. This is more or less what REBOUND in python outputs when you do

import rebound
sa = rebound.Simulationarchive("test.bin")
print(sa)

Answer 3 · 2024-07-08T19:55:07.000Z

sadump is for debugging mostly, to view what's in an SA. So naively I would just want to see variables and their value. If a sync is needed, the program should not do it, but give the info of times and positions.
Usually such programs would have an option to be verbose or brief, e.g. in nemo's tsf program the default is to never give more than a few lines, viz.

$ mkplummer - 100 | tsf -
char Headline[35] "init_xrandom: seed used 1720468486"
char History[29] "mkplummer - 100 VERSION=3.0b"
set SnapShot
  set Parameters
    int Nobj 100 
    double Time 0.00000 
  tes
  set Particles
    int CoordSystem 66306 
    double Mass[100] 0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 
      0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 
      0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 
      0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 0.0100000 
      . . .
    double PhaseSpace[100][2][3] 0.490367 -0.197528 0.0887513 
      -0.456912 -0.979979 -0.514264 0.213508 0.190619 -0.306886 
      -0.301723 -0.243252 0.228458 -1.33005 1.46871 -0.322172 
      -0.240406 0.346240 0.175299 -0.274907 -0.0223432 -0.331734 
      . . .
  tes
tes

Answer 4 · 2024-07-08T20:12:31.000Z

Got it. That could be useful. I'll need to think how to best implement that.

Answer 5 · 2024-07-09T21:33:31.000Z

I've added a tool to the sadump branch that will dump the contents of a Simulationarchive in a human readable form. The output looks like this:

==== START OF FILE ====
HEADER
	version: 4.4.1
	offsets: 32 bit
==== START OF BLOB[1] ====
FIELD
	name:   t
	type:   0
	size:   8 bytes
	dtype:  REB_DOUBLE
	value:  0.001
FIELD
	name:   gravity_ignore_terms
	type:   14
	size:   4 bytes
	dtype:  REB_UINT
	value:  1
FIELD
	name:   particles
	type:   85
	size:   768 bytes
	dtype:  REB_POINTER
	value:
		PARTICLE[0]
			x=-0.004063896721529716 y=-0.006088506063732321 z=-1.661805006420855e-06
			vx=0.0003889631739045965 vy=-0.0003684841339211458 vz=-1.81856273425785e-07
			ax=2.438447029526833e-06 ay=2.444455260260693e-06 az=-4.819843656862863e-08
			m=1.00000597682 r=0
			last_collision=0 hash=0
		PARTICLE[1]
			x=3.405140704292226 y=3.630102669845005 z=0.03423847099225465
			vx=-0.3254517409132432 vy=0.3207544115318524 vz=-0.0001553229628234582
			ax=1.218632542818788e-05 ay=1.058506434970154e-05 az=-6.407019381797532e-07
			m=0.0009547861040430418 r=0
			last_collision=0 hash=0
		PARTICLE[2]
			x=6.607772921681552 y=6.38107911089792 z=-0.136144991624712
			vx=-0.2426266271082831 vy=0.2323609208893521 vz=0.0009721885055098298
			ax=-0.008548047028193338 ay=-0.0082527271714226 az=0.0001773511882280337
			m=0.0002855837331505597 r=0
			last_collision=0 hash=0
		PARTICLE[3]
			x=11.16344369501856 y=16.03746791233747 z=0.3617820138079744
			vx=-0.189446290054355 vy=0.1200055354358959 vz=-0.001265586297583431
			ax=-0.001497823890645716 ay=-0.002152873510085392 az=-4.862794597655724e-05
			m=4.372731645458918e-05 r=0
			last_collision=0 hash=0
		PARTICLE[4]
			x=-30.1777369821396 y=1.911372148132238 z=-0.1538855124730154
			vx=-0.01264107291159435 vy=-0.1810018830526129 vz=0.002083150812942483
			ax=0.001092772816974943 ay=-6.930250423970282e-05 az=5.57274235634213e-06
			m=5.177591384487936e-05 r=0
			last_collision=0 hash=0
		PARTICLE[5]
			x=-21.38600061052271 y=32.07179030178278 z=2.492495152029605
			vx=-0.1028571796734571 vy=-0.1201724843612885 vz=0.03825644699689214
			ax=0.0003714700235760221 ay=-0.0005570967241017021 az=-4.329575578489609e-05
			m=7.4074074e-09 r=0
			last_collision=0 hash=0
FIELD
	name:   walltime
	type:   126
	size:   8 bytes
	dtype:  REB_DOUBLE
	value:  6e-06
FIELD
	name:   steps_done
	type:   137
	size:   8 bytes
	dtype:  REB_UINT64
	value:  1
FIELD
	name:   dt_last_done
	type:   145
	size:   8 bytes
	dtype:  REB_DOUBLE
	value:  0.001
FIELD
	name:   ri_whfast.p_jh
	type:   104
	size:   768 bytes
	dtype:  REB_POINTER
	value:
		PARTICLE[0]
			x=-1.582025339461428e-07 y=2.372504605535793e-07 z=1.843818561992657e-08
			vx=-7.608867842009315e-10 vy=-8.889695530573856e-10 vz=2.830016614481809e-10
			ax=-1.881771839768995e-22 ay=-2.20583640664797e-22 az=2.632604350033483e-24
			m=1.001341857294901 r=0
			last_collision=0 hash=0
		PARTICLE[1]
			x=3.409204601013756 y=3.636191175908737 z=0.03424013279726107
			vx=-0.3258407040871478 vy=0.3211228956657735 vz=-0.0001551411065500324
			ax=9.747878398661042e-06 ay=8.140609089440847e-06 az=-5.925035016111246e-07
			m=0.0009547861040430418 r=0
			last_collision=0 hash=0
		PARTICLE[2]
			x=6.60858488156454 y=6.383699164515765 z=-0.1361759904435845
			vx=-0.2427047807200974 vy=0.2324230956355045 vz=0.0009725183461780356
			ax=-0.008550494773428332 ay=-0.008255179391762896 az=0.0001773999518357168
			m=0.0002855837331505597 r=0
			last_collision=0 hash=0
		PARTICLE[3]
			x=11.16237069986763 y=16.03826715467865 z=0.361789856227171
			vx=-0.1894552174087523 vy=0.1200014165515711 vz=-0.001265533846611363
			ax=-0.001497832793306321 ay=-0.002152971120137823 az=-4.862978184489231e-05
			m=4.372731645458918e-05 r=0
			last_collision=0 hash=0
		PARTICLE[4]
			x=-30.17929744893202 y=1.911470983666754 z=-0.1538934697705487
			vx=-0.01264172657142404 vy=-0.1810112425161195 vz=0.002083258531014898
			ax=0.001092829326136797 ay=-6.93060919384372e-05 az=5.573030198123759e-06
			m=5.177591384487936e-05 r=0
			last_collision=0 hash=0
		PARTICLE[5]
			x=-21.38600061052271 y=32.07179030178278 z=2.492495152029605
			vx=-0.1028571796734543 vy=-0.1201724843612926 vz=0.03825644699689182
			ax=0.0003714700263239646 ay=-0.0005570967282228146 az=-4.329575610517563e-05
			m=7.4074074e-09 r=0
			last_collision=0 hash=0
FIELD
	name:   end
	type:   9999
	size:   0 bytes
BLOB[1]
	index:        1 bytes
	offset_prev:  1700 bytes
	offset_next:  1700 bytes
==== END OF FILE ====

This can quickly become quite large. But maybe it is useful for debugging.

Answer 6 · 2024-07-09T22:51:25.000Z

yes, this could quickly become large. But the defaults in ncdump and h5dump are large too. In NEMO's equivalent "tsf tool you could consider:

an option to only show up to N bodies, where N can be selected
an option to show fewer digits of floating point numbers

I used your new program already to debug (confirm) my case why I'm missing a dump at t=0.3 in the example I showed in my talk. It should have contained 11 snapshot, 0 to 1 in steps of 0.1, but 0.3 is missing.