Zero-latency links don't give a warning or assertion error

[amroawad2]

New Issue for sst-elements

1 - Detailed description of problem or enhancement

Having a zero-latency link can hang the simulator when using parallel sst, e.g., sst -n 2. It is worthy to have a warning or assertion when the latency is zero.

2 - Describe how to reproduce

changing the gupsgen_mmu.py test in samba, and running sst with -n 2 will hang.

3 - What Operating system(s) and versions

4 - What version of external libraries (Boost, MPI)

5 - Provide sha1 of all relevant sst repositories (sst-core, sst-elements, etc)

6 - Fill out Labels, Milestones, and Assignee fields as best possible

[ghost]

I believe that historically, we've allowed simulations to have links with a declared latency of zero, but they get (silently) reset to the minimum timebase. @feldergast , is that correct?

Is there any reason why we shouldn't just make the core's checkForStructuralErrors() give an error on zero-latency links? ( @feldergast @nmhamster @afrodri )

[nmhamster]

@bjmoor - my preference would be to have the simulation error. I think it will avoid problems later down the road.

[ghost]

It appears that the scheduler element sets their links to "0 ns". If we are to make a change in the core on this, scheduler will need to be updated first. @vjleung @fkaplan3 @nmhamster

[allevin]

Suggested solution is to have it generate a warning.