Uncertainty Quantification App

[mmcleod89]

Changes

• Add UQ executable to cmake
• Refactors various setup steps out of purify main and into separate functions so that they can be shared with UQ
• Calculates likelihood / prior terms assuming they are L2 and L1 norms (will need update when pytorch models are in place)

Currently needs

• I think sigma can be derived from the purify config parameters so that should be updated
• We need some purify config files to test the UQ and purify apps with to make sure nothing is breaking
• There are two paths for the setup, one using a purify config file and one based on the algo_factory test case. This is so there's something I can run this with and check that the app is doing something sensible in lieu of a purify config file but it should be taken out later.
• Some appropriate tests need to be devised.

Issues
Replacing the line:
const VectorC wavelet_rep = wavelet_operator->adjoint() * image;
in UQ with
const auto wavelet_rep = wavelet_operator->adjoint() * image;
causes a seg-fault, although I don't know why yet. The inferred type of wavelet_rep is AppliedFunction, and in the next line when we call the sum and things are evaluated we get a seg-fault.

[mmcleod89]

Now depends on the sopt onnx_tweaks pull request being merged before it will work.

Also does some refactors to where information is found relating to the types of the functions f and g

[mmcleod89]

@tkoskela The tests seem to be failing on this branch at the moment because it can't find files in the local install folder

 /Users/runner/work/purify/purify/cpp/tests/utils.cc:88: FAILED:
due to unexpected exception with message:
  Could not open file /Users/runner/work/purify/purify/local/data/vla/at166B.
  3C129.c0I.vis

but they do appear to be there when I build locally on my machine, and the file is still in the data folder in this branch of the repository so nothing appears to have changed there. Any ideas why this might be happening now? (I have also merged development into this branch to bring it up to date.)

[tkoskela]

Strange. The log file claims the file has been installed.
🤔

We seem to be installing it twice! But that shouldn't break anything

[mmcleod89]

Looking at the names more closely I can see at166B.3C129.c0.vis being installed, and ends up in my local install, but not at166B.3C129.c0I.vis (with an I before .vis). I can't find this file in the data on the development branch, but it is referenced in the utils.cc tests and has been for years.

What appears to have happened is that it has been broken on my branch, because I added in some error handling to check if a file had been opened successfully and throw an exception if a file didn't exist, which is now breaking this test. I assume that the c0I.vis is a typo that's just been perpetuated for years and that it should be c0.vis since this file doesn't seem to have ever existed, but it is funny that the test used to pass despite the fact that it never actually loaded any data.

[tkoskela]

I guess it comes down to what happens here

purify/cpp/purify/uvw_utilities.cc

Lines 167 to 171 in 003984a

	t_real streamtoreal(std::ifstream &stream) {
	std::string input;
	stream >> input;
	return std::stod(input);
	}

if the stream is not reading a real file. Not sure if this is related in any way but I've actually got errors from this when running the benchmarks. I assumed it was due to multiple jobs trying to access the same file so I just disabled caching the randomly generated visibilities in

purify/cpp/benchmarks/utilities.cc

Lines 104 to 114 in e697291

	if (false) {
	PURIFY_INFO("Reading random visibilities from file {}", vis_file);
	uv_data = utilities::read_visibility(vis_file, true);
	uv_data.units = utilities::vis_units::radians;
	} else {
	PURIFY_INFO("Generating random visibilities");
	t_real const sigma_m = constant::pi / 3;
	uv_data = utilities::random_sample_density(size, 0, sigma_m, max_w);
	uv_data.units = utilities::vis_units::radians;
	// utilities::write_visibility(uv_data, vis_file, true);
	}

[mmcleod89]

Tests are passing now so we should be good to go once it's been reviewed :)

[mmcleod89]

I guess it comes down to what happens here

purify/cpp/purify/uvw_utilities.cc

Lines 167 to 171 in 003984a

	t_real streamtoreal(std::ifstream &stream) {
	std::string input;
	stream >> input;
	return std::stod(input);
	}

if the stream is not reading a real file. Not sure if this is related in any way but I've actually got errors from this when running the benchmarks. I assumed it was due to multiple jobs trying to access the same file so I just disabled caching the randomly generated visibilities in

purify/cpp/benchmarks/utilities.cc

Lines 104 to 114 in e697291

	if (false) {
	PURIFY_INFO("Reading random visibilities from file {}", vis_file);
	uv_data = utilities::read_visibility(vis_file, true);
	uv_data.units = utilities::vis_units::radians;
	} else {
	PURIFY_INFO("Generating random visibilities");
	t_real const sigma_m = constant::pi / 3;
	uv_data = utilities::random_sample_density(size, 0, sigma_m, max_w);
	uv_data.units = utilities::vis_units::radians;
	// utilities::write_visibility(uv_data, vis_file, true);
	}

So normally std::stod would throw an exception if the string were blank, but this is wrapped in a for loop from 0 to rows and rows is getting set to 0 because there's nothing to read and the vectors are all just empty

[tkoskela]

Didn't do a super thorough review, but I checked it builds on my machine and went through the changes and nothing crazy caught my eye.