jkeger/arctic

AlgoRithm for Charge Transfer Inefficiency (CTI) Correction

arctic's Issues

Cannot compile ArCTIC under MacOS

It's not possible to compile ArCTIC under MacOS with the clang compiler.

Here is the error message:

$ make gsl
... everything is fine ...
$ make lib
...
d: unknown option: -rpath=/System/Volumes/Data/work/sw/fred_arctic/arctic/gsl/lib/
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libarctic.so] Error 1

Speed up compilation when building the 'gsl' library

Building the library 'gsl' with the command make gsl is running in one core.

This compilation process could be easily reduced by compiling 'gsl' in parallel mode (see https://www.gnu.org/software/make/manual/html_node/Parallel.html)

To activate parallel mode, all you have to do is replace all make <something> in get_gsl.sh by make -j <something>.

Too much logging information by default

Dear all,

I just found a 'nasty' bug.

When 'arctic' is used (for example) to remove CTI, lots of debug information is shown even when the verbosity level is set to 0 .

So when we run our Python script using Arctic from the command line, we get a lot of logging information (it's fine) and the script works (that's good). But when we run the script using JupyterLab, the code is blocking (not good !) because there is too many logging information (even if it's not displayed in JupyterLab)

The only solution I found is to replace in the C++ code the following statements print_v(0, "..."); with print_v(1, "...").

I will create a new pull request for a possible solution.

Cheers,
Frederic

Run Time With Noise vs No Noise

The following script compares two datasets arctic clocking.

https://github.com/Jammy2211/autocti_workspace_test/blob/main/imaging_ci/profiling/arctic/noise.py

The datasets are identical, except one has Gaussian noise added to it whereas the other does not.

The clocking times for arctic for these two datasets are:

Clocking Time = 2.2919435501098633
Clocking Time No Noise = 7.8446900844573975

Experiments I did previously the latter time was going up to 12 seconds, albeit I cant reproduce this now. This likely depends on the exact nature of the image I simulate, but the general slow-down for noiseless data is likely a generic problem.

I'll send the files on teams as github wont let me.

Initial conditions of pixel bounce

ICs of pixel bounce spread countinertuitively between kA and kv parameters. They work, but aren't split properly.

ROEChargeInjection does not work via wrapper

If I pass ROEChargeInjection to the wrapper, it does not calls it set_express_matrix_from_rows_and_express and set_store_trap_states_matrix methods, instead reverting to the methods of the default ROE class.

I have put a print(roe->type) before the following line in add_cti.cpp`:

roe->set_express_matrix_from_rows_and_express(n_rows, express, offset);

And the type is indeed type 1, indicating that the Python wrapper appears to be passing the correct type.

My best guess is that the inheritance structure is failing to overwrite the methods correctly?

Make core command failing

Hi all,

I have just tried to install the latest version of arctic from source using the installatiion instructions from the readme but when I come to the make commands I get the following error:

I am not sure if the readme or the code (or even my poor C installation skills!) that need reviewing though.

Thanks!

Not dumping uneccessary data from memory

---

name: Holding into too much memory
about: File a bug/issue
title: '[BUG] Not dumping uneccessary data from memory '
labels: Bug, Question

---

Description:

Using parallelisation software to run through arctic multiple times. Each run increases the memory usage of the workers adn does not release memory, causing crashes for larger simulations.

This has worked fine before with previous master commit #0a9ff64fb8a263d8d8a85924c7b6c11cbb276bbd - workers didn't have memory usage beyond roughly 0.5GB. Only new master seems to have this problem.

Attached images:

Image of workers used, orange indicating high usage