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

[MRG] make L5/L2 pyr have different geometry options in GUI #848

Merged
merged 5 commits into from
Aug 6, 2024

Conversation

ntolley
Copy link
Contributor

@ntolley ntolley commented Aug 1, 2024

The current implementation of the cell parameter widget skips over a compartment of L5 pyramidal cells

This PR correctly updates the compartment parameters, as well as improves testing to make sure the GUI network matches the API instantiated network

@kmilo9999
Copy link
Collaborator

@ntolley The code looks for variables in the params_default:get_L2Pyr_params_default() script and match them with the 3rd parameter in the large gui.py dictionary. You removed # ('Apical Dendrite 2 length', 'micron', '**apical2_L**'),() , but that one still exist in params_defaul
Let me know the next steps.

@ntolley
Copy link
Contributor Author

ntolley commented Aug 2, 2024

@kmilo9999 the original code actually didn't have an apical_2 key, the commented out line was just for my own reference

L2 and L5 pyramidal cells differ in that L5_pyramidal cells have an apical_2 section, whereas L2_pyramidal cells do not (which matches with the entries in get_L2Pyr_params_default() )

What I'm trying to do is have the apical_2 key be looked up only when an L5 pyramidal cell is selected

@kmilo9999
Copy link
Collaborator

kmilo9999 commented Aug 5, 2024

@ntolley I think the loops in the add_cell_parameters_tab need to be reworked. It's not doing what it supposed and the logic it's hard to follow.
Should I work it on a different PR or on this one ?

@ntolley
Copy link
Contributor Author

ntolley commented Aug 5, 2024

@kmilo9999 I agree we can revamp the logic in a followup PR

In any case, I think I've updated the mappings that needed to be added and wrote some tests that they match what we get from making a network with the CLI

Do you mind reviewing to make sure everything is correct?

@ntolley ntolley changed the title WIP: make L5/L2 pyr have different geometry options in GUI [MRG] make L5/L2 pyr have different geometry options in GUI Aug 5, 2024
@kmilo9999
Copy link
Collaborator

kmilo9999 commented Aug 5, 2024

@ntolley
Are you getting the right dipoles if you run with/out the UI cell params?

This is what I got:

Using UI cell params
image

Not using the UI cell params (default values)
image

Correct me if I am wrong.
The UI is just loading the default values from params_default and send it to the simulation. Running the default UI values should throw the same graph as if there was no UI cell params.

@@ -1669,7 +1701,12 @@ def _init_network_from_widgets(params, dt, tstop, single_simulation_data,
cell_type = vbox_key.split()[0]
update_function(single_simulation_data['net'], cell_type,
cell_param_list.children)
break
# break # why is this here?
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kmilo9999 let me know when you have time to look at this

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's a small optimization.
Once the conditions are meet and a function is called, the loop doesnt need to continue to go through unnecessary iterations. This helps on correctness to guaranty no other calls to the same conditions are made.

@@ -1963,7 +2031,7 @@ def update_common_dendrite_sections(sections, mechs_params):
name for name in sections.keys() if name != 'soma'
]
for section in dendrite_sections:
sections[section].mechs.update(mechs_params)
sections[section].mechs.update(deepcopy(mechs_params))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this deepcopy necessary ? This operations hit the performance of the app

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it is necessary because a nested dictionary is being added, I tried a regular .copy() and found that the inner dictionary was still pointing to the same variable

This is only necessary for the ar mechanism since gbar_ar is a partial function who's outputs depend on the geometry of each section

Copy link
Collaborator

@kmilo9999 kmilo9999 Aug 6, 2024

Choose a reason for hiding this comment

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

I'll revisit this in a future PR. Because of my main logic you were force to use the deepcopy. I can rework it to avoid this call

Copy link
Collaborator

Choose a reason for hiding this comment

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

Copy link
Collaborator

@kmilo9999 kmilo9999 left a comment

Choose a reason for hiding this comment

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

I left a comment in this PR. If you think everything is running correctly then I believe is fine.

@ntolley
Copy link
Contributor Author

ntolley commented Aug 6, 2024

Sounds great @kmilo9999!

I'm good with the current changes so feel free to merge when you're ready. I have some ideas for variable name changes to increase clarity but we can work that out separately

@kmilo9999 kmilo9999 merged commit 282fdbc into jonescompneurolab:master Aug 6, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants