I'd like to simulate some signals / paths from older version of the package and check that new version produce the same output. None of the current tests really test if someone has messed with the simulation.

When using MJDSigGen, I seem to get the following error at random:

julia(24106,0x107048dc0) malloc: *** error for object 0x7f9a308a3400: pointer being freed was not allocated
julia(24106,0x107048dc0) malloc: *** set a breakpoint in malloc_error_break to debug

signal (6): Abort trap: 6
in expression starting at none:0
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 41926025 (Pool: 41914119; Big: 11906); GC: 36

I think I can reproduce the error with the following snippet but I'm unsure if the error I get there is actually the same as the error I get when I just use MJDSigGen in my other code. I don't call signal_calc_finalize! explicitly anywhere. I suspect julia garbage collection might be calling it though, so may be that's why I keep getting errors.

using MJDSigGen: signal_calc_init, signal_calc_finalize!

setup = signal_calc_init(path_to_config)
signal_calc_finalize!(setup)

# Here comes the error...
setup2 = signal_calc_init(path_to_config)

Edit: actually, if I don't run that snippet in Juno, but just run it in the terminal I can reproduce the error with just:

using MJDSigGen: signal_calc_init

setup = signal_calc_init(path_to_config)
setup2 = signal_calc_init(path_to_config)

This is an issue for me, since I'd like to be able to run signal generation from one config file in parallel in multiple processes.

Found in #11.

We're using MJDSigGen.jl for our work and I was wondering if anybody is still maintaining this code. We have some patches we might want to open merge requests for.

For testing especially, it would be good to define what makes two setup objects equal. When we decide what the essential properties of a setup object are, we can also write a nicer show method.

I'm thinking at a minimum we should have

• a basic usage section (start with config -> fieldgen -> signal_calc_init -> get_signal! -> get path / charge size, etc. from setup)
• docstrings for SigGenSetup, get_signal!, fieldgen, signal_calc_init

At some point I wasted a few days of compute time because I had accidentally left diffusion, acceleration and repulsion on when I didn't mean to. Since then I turn group effects off in my configs, so the config really only defines the geometry, impurities, etc. and I configure group effects in the code (see following example), because turning them on or off tends to be part of the logic of the code, rather than a preset config that stays constant.

result = with_group_effects(setup, E, cloud_size) do stp
    # do something with the stp, using group effects
    return result
end

For people who usually need group effects but sometimes turn it off, I can also add another method like so:

result = with_group_effects(:off, setup) do stp
    # do something with the stp, not using group effects
    return result
end

This way, people can turn it :off or :on.

If there's interest, I can make a pull request and add it in. May be in utils.jl?

• We should see about merging the c-code here with the upstream siggen here
• Then we can remove the dependencies here and build dependencies from the upstream repo directly