Tawhiri/current predictor - Revision history

EllieClifford: Changed redirect target from Tāwhirimātea to Tāwhirimātea#CUSF C Predictor Notes

2021-04-29T21:20:03Z

Changed redirect target from Tāwhirimātea to Tāwhirimātea#CUSF C Predictor Notes

← Older revision		Revision as of 21:20, 29 April 2021
Line 1:		Line 1:
	#REDIRECT [[Tāwhirimātea]]		#REDIRECT [[Tāwhirimātea#CUSF C Predictor Notes]]

EllieClifford: Redirected page to Tāwhirimātea

2021-04-29T18:04:18Z

Redirected page to Tāwhirimātea

← Older revision		Revision as of 18:04, 29 April 2021
Line 1:		Line 1:
	[[~~Category:Deleted~~]]		#REDIRECT [[Tāwhirimātea]]

EllieClifford: "Remove old Tawhiri pages"

2021-04-29T17:52:13Z

"Remove old Tawhiri pages"

← Older revision		Revision as of 17:52, 29 April 2021
Line 1:		Line 1:
	~~== CUSF C Predictor Notes ==~~		[[Category:Deleted]]

	~~=== Source, Versions ===~~

	~~These notes refer to~~ [~~https://github.com/cuspaceflight/cusf-standalone-predictor cusf-standalone-predictor 0d32e97]~~ [~~https~~:~~//github.com/cuspaceflight/cusf-landing-prediction cusf-landing-predicton 5e6e9a9~~]

	~~The C binaries in the hourly and the standalone predictors have the following differences:~~

	* Standalone has an 'alarm' option (e689ab9) - Kills the predictor with alarm(2)/SIGALRM after 10 minutes if it does not exit gracefully.
	* Standalone is far stricter on errors (e358188, 1fc73b9) - Changed several WARNs to ERRORS, and exit as soon as any ERROR occurs.

	~~=== Functions ===~~

	* pred.c

	~~<pre> * main~~
	* parses options
	* sets up wind cache: wind_file_cache_new
	* parses scenario(s)
	* sets up altitude model: altitude_model_new
	* run_model()
	* N.B. FILE output, kml_file ‘passed’ via global variables
	* misc cleanup
	* small kml header/footer functions
	* run_model.c
	* run_model
	* repeatedly:
	* calls advance_one_timestep
	* calls write_position (every N steps)
	* sorts states by log likelihood (currently hardcoded: only 1 state)
	* write_position (final position)
	* advance_one_timestep
	* for each state:
	* altitude_model_get_altitude()
	* get_wind()
	* random_sample_normal for wind speed; adds randomness to windspeed and updates log likelihood (currently hardcoded rmserror=0 so does not modify speed)
	* updates state (i.e., forwards euler / rectangles integration)
	* get_wind
	* wind_file_cache_find_entry for current latitude and longitude; returns a wind file before now and after now
	* check both contain current point (in space); before < now < after
	* wind_file_get_wind on both files
	* return x, y velocity; mean variance (mean flattens 2D -> 1D)
	* altitude.c
	* get_density
	* (simple?) atmosphere density model
	* "uses NASA model from http://www.grc.nasa.gov/WWW/K-12/airplane/atmosmet.html"
	* this calculation is used for calculating a descent rate only
	* altitude model:
	* constant ascent
	* descent: assume terminal velocity
	* NB: drag coefficient = descent rate * magic constant (magic constant is in pred.c)
	* seems to be designed with multiple altitude models (e.g., floating, etc.) in mind, not used.
	* wind/wind_file.c
	* functions to read wind files (csv)
	* wind_file_get_wind
	* not thread safe
	* searches wind file axes for desired location (lat, lon, height)
	* linear interpolation in 3D for x and y velocity
	* estimates wind variance by calculating variance (i.e., E(x^2) - E(x)^2) of the 8 points of the cube-like-thing that we interpolated in
	* wind/wind_file_cache.c
	* scans a directory for wind files, parses headers to determine lat/lon ranges, time.
	* wind_file_cache_find_entry gets the best file for a certain point in space/time
	* omitted: util/ - some functions referred to, but have self explanatory names
	~~</pre>~~
	~~=== Remarks ===~~

	'''Is it messy?''' Not really. I think the majority of the pain in adding to it would be having to write in C; the bits that manage files and loading scenarios etc. are really quite tedious in C. Certainly the prediction bit itself benefits from speed. Hopefully this will not be an issue. Could possibly have a python/C mix if required.

	'''Is it worth tidying up?''' Tidying would probably just consist of changing it to conform to what we think C should look like rather than actual changes. Most of the things are pretty reasonable. It does sometimes segfault. Might be worth fixing that.

	~~'''Is it easy to redo in python?''' Not too much effort. Certainly aren't even that many lines of code in here; hopefully LOC would drop dramatically in python too.~~

	'''Is it worth redoing in python?''' IMO yes because then we can add cool new things. e.g., I would really like to have some better integration: I’m kind of hoping it will be possible to integrate from entering a cube to leaving a cube in one step. Might be possible to still monte carlo while integrating cube to cube in one step. Or multiple configurable altitude models [e.g., float].

EllieClifford: "Add old wiki"

2021-04-19T18:58:40Z

"Add old wiki"

New page

== CUSF C Predictor Notes ==

=== Source, Versions ===

These notes refer to [https://github.com/cuspaceflight/cusf-standalone-predictor cusf-standalone-predictor 0d32e97] [https://github.com/cuspaceflight/cusf-landing-prediction cusf-landing-predicton 5e6e9a9]

The C binaries in the hourly and the standalone predictors have the following differences:

* Standalone has an 'alarm' option (e689ab9) - Kills the predictor with alarm(2)/SIGALRM after 10 minutes if it does not exit gracefully.
* Standalone is far stricter on errors (e358188, 1fc73b9) - Changed several WARNs to ERRORS, and exit as soon as any ERROR occurs.

=== Functions ===

* pred.c

<pre> * main
* parses options
* sets up wind cache: wind_file_cache_new
* parses scenario(s)
* sets up altitude model: altitude_model_new
* run_model()
* N.B. FILE *output, *kml_file ‘passed’ via global variables
* misc cleanup
* small kml header/footer functions
* run_model.c
* run_model
* repeatedly:
* calls advance_one_timestep
* calls write_position (every N steps)
* sorts states by log likelihood (currently hardcoded: only 1 state)
* write_position (final position)
* advance_one_timestep
* for each state:
* altitude_model_get_altitude()
* get_wind()
* random_sample_normal for wind speed; adds randomness to windspeed and updates log likelihood (currently hardcoded rmserror=0 so does not modify speed)
* updates state (i.e., forwards euler / rectangles integration)
* get_wind
* wind_file_cache_find_entry for current latitude and longitude; returns a wind file before now and after now
* check both contain current point (in space); before < now < after
* wind_file_get_wind on both files
* return x, y velocity; mean variance (mean flattens 2D -> 1D)
* altitude.c
* get_density
* (simple?) atmosphere density model
* "uses NASA model from http://www.grc.nasa.gov/WWW/K-12/airplane/atmosmet.html"
* this calculation is used for calculating a descent rate only
* altitude model:
* constant ascent
* descent: assume terminal velocity
* NB: drag coefficient = descent rate * magic constant (magic constant is in pred.c)
* seems to be designed with multiple altitude models (e.g., floating, etc.) in mind, not used.
* wind/wind_file.c
* functions to read wind files (csv)
* wind_file_get_wind
* not thread safe
* searches wind file axes for desired location (lat, lon, height)
* linear interpolation in 3D for x and y velocity
* estimates wind variance by calculating variance (i.e., E(x^2) - E(x)^2) of the 8 points of the cube-like-thing that we interpolated in
* wind/wind_file_cache.c
* scans a directory for wind files, parses headers to determine lat/lon ranges, time.
* wind_file_cache_find_entry gets the best file for a certain point in space/time
* omitted: util/ - some functions referred to, but have self explanatory names
</pre>
=== Remarks ===

'''Is it messy?''' Not really. I think the majority of the pain in adding to it would be having to write in C; the bits that manage files and loading scenarios etc. are really quite tedious in C. Certainly the prediction bit itself benefits from speed. Hopefully this will not be an issue. Could possibly have a python/C mix if required.

'''Is it worth tidying up?''' Tidying would probably just consist of changing it to conform to what we think C should look like rather than actual changes. Most of the things are pretty reasonable. It does sometimes segfault. Might be worth fixing that.

'''Is it easy to redo in python?''' Not too much effort. Certainly aren't even that many lines of code in here; hopefully LOC would drop dramatically in python too.

'''Is it worth redoing in python?''' IMO yes because then we can add cool new things. e.g., I would really like to have some better integration: I’m kind of hoping it will be possible to integrate from entering a cube to leaving a cube in one step. Might be possible to still monte carlo while integrating cube to cube in one step. Or multiple configurable altitude models [e.g., float].