Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document kernel status dictionary entries #1373

Merged
merged 16 commits into from
Apr 23, 2020

Conversation

morales-gregorio
Copy link
Contributor

This is the PR trying to solve Issue #1350

I have looked into nest.help("kernel") and I found a few issues.

  • initial_connector_capacity, large_connector_limit, large_connector_growth_factor are present in the help documentation but they do not seem to be present in the kernel status dictionary from NEST >=2.14. I have removed them from the list.
  • grng_seed and rng_seed are specified as write only, but the GetKernelStatus() does return them, they can also be read (I removed the write only tag from their description).
  • There is a long list of keys that are present in the kernel dictionary (NEST 2.18.0) and not documented in nest.help("kernel"):
 ['adaptive_spike_buffers',
 'adaptive_target_buffers',
 'buffer_size_secondary_events',
 'buffer_size_spike_data',
 'buffer_size_target_data',
 'growth_factor_buffer_spike_data',
 'growth_factor_buffer_target_data',
 'keep_source_table',
 'local_spike_counter',
 'max_buffer_size_spike_data',
 'max_buffer_size_target_data',
 'max_num_syn_models',
 'sort_connections_by_source',
 'structural_plasticity_synapses',
 'structural_plasticity_update_interval',
 'time_collocate',
 'time_communicate']

I have added them, their types and whether they are read only or can be read and written. However their descriptions should be filled before this PR can be merged to master. (Marked the descriptions with TODO flags)

Best,
Aitor

@terhorstd terhorstd added ZC: Documentation DO NOT USE THIS LABEL I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) ZP: PR Created DO NOT USE THIS LABEL S: Normal Handle this with default priority T: Maintenance Work to keep up the quality of the code and documentation. labels Jan 6, 2020
@terhorstd terhorstd added this to the NEST 3.0 milestone Jan 6, 2020
@jakobj
Copy link
Contributor

jakobj commented Feb 12, 2020

great, thanks @morales-gregorio! here are some descriptions of the entries marked with TODO, partly extracted directly from the source files:

  • adaptive_spike_buffers: whether MPI buffers for communication of spikes resize on the fly
  • adaptive_target_buffers: whether MPI buffers for communication of connections resize on the fly
  • buffer_size_spike_data: total size of MPI buffer for communication of spikes
  • buffer_size_target_data: total size of MPI buffer for communication of connections
  • growth_factor_buffer_spike_data: if MPI buffers for communication of spikes resize on the fly, grow them by this factor each round
  • growth_factor_buffer_target_data :if MPI buffers for communication of connections resize on the fly, grow them by this factor each round
  • keep_source_table : whether to keep source table after connection setup is complete
  • max_buffer_size_spike_data : maximal size of MPI buffers for communication of spikes
  • max_buffer_size_target_data : maximal size of MPI buffers for communication of connections
  • max_num_syn_models : maximal number of synapse models supported
  • sort_connections_by_source : whether to sort connections by their source; increases construction time of presynaptic data structures, decreases simulation time if the average number of outgoing connections per neuron is smaller than the total number of threads

@morales-gregorio
Copy link
Contributor Author

morales-gregorio commented Feb 13, 2020

Thanks @jakobj for the collection efforts! I have included those to the PR. Now only the descriptions for:

buffer_size_secondary_events
local_spike_counter
structural_plasticity_synapses
structural_plasticity_update_interval
time_collocate
time_communicate

are missing. Any suggestions on where such descriptions can be found? or who may know?

@stinebuu
Copy link
Contributor

@morales-gregorio I think something happened when you merged your branch with master, your PR now contains 1185 changed files :)

When it comes to local_spike_counter it is the number of generated spike events during simulation.

@heplesser
Copy link
Contributor

@morales-gregorio I am sorry I did not get around to reviewing your PR before the NEST-3 merger. As @stinebuu pointed out, something seems to have gone wrong when you merged a recent master into your PR. Could you try to either do this merge once more, or create a new PR, adding the new documentation to the current master? I will be fast in the next round!

@morales-gregorio
Copy link
Contributor Author

Hey @heplesser @stinebuu Thanks for having a look. Something went very wrong with my PR indeed, I will look into that possibly creating a new PR.
However, before anything can be merged I still need definitions for these keywords:

buffer_size_secondary_events
local_spike_counter
structural_plasticity_synapses
structural_plasticity_update_interval
time_collocate
time_communicate

Do you know what they are and what they do? Or do you know who knows?
Thanks!

@heplesser
Copy link
Contributor

heplesser commented Mar 24, 2020

buffer_size_secondary_events

Size of MPI buffers for communicating secondary events (in bytes, per MPI rank, for developers)

local_spike_counter

Number of spikes fired by neurons on a given MPI rank since NEST was started or the last ResetKernel. Only spikes from "normal" neurons (neuron models with proxies) are counted, not spikes generated by devices such as poisson_generator.

@sdiazpier Could you explain the next two

structural_plasticity_synapses
structural_plasticity_update_interval

@suku248 or @jarsi Could you explain these two:

time_collocate
time_communicate

@sdiazpier
Copy link
Contributor

structural_plasticity_synapses
Is a dictionary which defines all synapses which are plastic for the structural plasticity algorithm. Each entry in the dictionary is composed of a synapse model, the pre synaptic element and the post synaptic element.
structural_plasticity_update_interval
Defines the time interval in ms at which the structural plasticity manager will make changes in the structure of the network (creation and deletion of plastic synapses).

@jarsi
Copy link
Contributor

jarsi commented Mar 24, 2020

The keywords

time_collocate
time_communicate

should log the time spent collocating and communicating. It seems that these variables have lost their purpose and they do not seem to properly function anymore. From my experiments I know that they worked with the 4g Kernel. If I remember correctly, they do not work with current master anymore.

We recently had a conference on a basic instrumentation of NEST. The results have been gathered in issue #1471. These two variables were also part of the discussion. Most probable both are obsolete and will be replaced with something else.

@morales-gregorio
Copy link
Contributor Author

@sdiazpier @jarsi thanks for your responses!

I could omit time_collocate and time_communicate from the list of parameters in the documentation. Or I could also annotate them with the descriptions from issue #1471 and note that these are now deprecated.

Whatever is preferrable, what do you think?

@heplesser
Copy link
Contributor

I could omit time_collocate and time_communicate from the list of parameters in the documentation. Or I could also annotate them with the descriptions from issue #1471 and note that these are now deprecated.

Whatever is preferrable, what do you think?

I would omit them now. Once #1471 brings a properly defined set of timings to the table, the PR can add the documentation. We need to keep dependencies between PRs and issues down ;).

@morales-gregorio
Copy link
Contributor Author

Hi!

I have reset to the original fork master (which has temporarily closed this PR), pulled from the upstream master and I now pushed one commit with all the documented parameters into it.

Please have a look if you think there is something wrong. I have ignored time_collocate and time_communicate as suggested. I have also added all other descriptions as provided by the different people, such that no parameter is missing a description.

Best,
Aitor

Copy link
Contributor

@heplesser heplesser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@morales-gregorio I think we should not duplicate this large amount of documentation in SetKS and GetKS. We will not manage to keep it in sync. I am not decided yet if I would place the doc with Get or Set: In Get, all parameters apply, but in Set the documentation is most needed. So maybe Set is the best place. As default I would assume all params to be read/write, and mark only those that are read-only explicitly. Given the very long list of parameters, I would suggest grouping them with sub-headings.

@sarakonradi I'd much appreciate your input.

resolution : double
The resolution of the simulation (in ms)
time : double
The current simulation time
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should either give units for all quantities or for none.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @heplesser thanks for spotting this. I would argue in favor of providing units always. But I am not sure which units are needed in each case.

Is it always milliseconds for time-related keywords? What about the rest?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point! In the kernel, all time-related keywords are in ms. The only other quantities with units I spot are potentially the various buffer sizes, although they may also be number of buffer elements, not size in bytes (@suku248 @jakobj could you help on this?); and the wfr_tol, which might be relative or absolute (@janhahne @ddahmen @rgutzen could you provide details?).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@heplesser wft_tol is the absolute tolerance for the iterative scheme to stop (every membrane potential/rate change from one iteration to the next needs to be below this value for all neurons that use waveform relaxation).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@janhahne So this means that if I simulate a network of spiking neurons with gap junctions, wfr_tol would have units of mV, because it refers to membrane potential, and if I simulate a network of rate neurons it would have units of spikes/second?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@heplesser yes, exactly :)

@heplesser heplesser requested review from sarakonradi and removed request for hakonsbm April 2, 2020 14:25
Copy link
Contributor

@sarakonradi sarakonradi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@morales-gregorio Thanks a lot for your work! Just added two minor comments. I agree with @heplesser about grouping the parameters into sublists.

@jhnnsnk If you have anything to add regarding print_time, please let us know.

Comment on lines 277 to 279
defines all synapses which are plastic for the structural plasticity
algorithm. Each entry in the dictionary is composed of a synapse model,
the pre synaptic element and the post synaptic element. (read/write)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be Defines the time interval in ms at which the structural plasticity manager will make changes in the structure of the network (creation and deletion of plastic synapses).?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for spotting this one! Yes indeed

If MPI buffers for communication of spikes resize on the fly, grow
them by this factor each round (read/write)
growth_factor_buffer_target_data : float
if MPI buffers for communication of connections resize on the fly, grow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest capitalizing the first letter of every definition for consistency.

@sarakonradi sarakonradi mentioned this pull request Apr 3, 2020
24 tasks
If MPI buffers for communication of spikes resize on the fly, grow
them by this factor each round (read/write)
growth_factor_buffer_target_data : float
if MPI buffers for communication of connections resize on the fly, grow
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if MPI buffers for communication of connections resize on the fly, grow
If MPI buffers for communication of connections resize on the fly, grow

max_num_syn_models : int
Maximal number of synapse models supported (read only)
sort_connections_by_source : bool
whether to sort connections by their source; increases construction
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
whether to sort connections by their source; increases construction
Whether to sort connections by their source; increases construction

@sarakonradi
Copy link
Contributor

@morales-gregorio Thanks for the update! It looks like something went wrong after merging master, since all the files that were changed in other PRs appear under "Files changed" now. Perhaps it is best to undo the last commit and merge master again?

@morales-gregorio
Copy link
Contributor Author

Hey @sarakonradi I think that the faulty history is now fixed, I figured out that using rebase is a way better idea than merging master to my branch.

Copy link
Contributor

@sarakonradi sarakonradi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @morales-gregorio, thanks for fixing the history! Overall, it looks good to me. I replied to @heplesser's comment regarding Other parameters inline.

Talking with @sarakonradi we noticed that most other functions in this file (an potentially most others) do not follow the standard for the headings (i.e. have no blank line after the heading).
Maybe a future PR could handle that? It would have to be rather large one, making changes to the docstring of most functions, but could be used to establish the standard for the documentation.

Yes, definitely. We should examine the formatting of all functions in a different PR later on.

@@ -190,99 +190,134 @@ def SetKernelStatus(params):

Other parameters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @heplesser regarding Other parameters and suggest changing it toParams dictionary or Parameter dictionary.

@morales-gregorio
Copy link
Contributor Author

@sarakonradi @heplesser I just went ahead and changed Other parameters -> Params dictionary.
Which I believe addresses all review comments

Copy link
Contributor

@sarakonradi sarakonradi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

@heplesser heplesser merged commit 1d10715 into nest:master Apr 23, 2020
@terhorstd terhorstd changed the title Doc kernelstatus Document kernel status dictionary entries Jun 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I: No breaking change Previously written code will work as before, no one should note anything changing (aside the fix) S: Normal Handle this with default priority T: Maintenance Work to keep up the quality of the code and documentation.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Suggestion to improve nest.SetKernelStatus() and nest.GetKernelStatus() documentation
10 participants