forked from benoit-girard/sBCBG
-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes.txt
467 lines (369 loc) · 14.3 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
Optimisation de paramètres :
1.1) optimisation à la main du modèle 9 (celui de la table 9 du papier).
gmsn=4.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=11.
iegpi=10.
1.2) grid search à l'aide de Sango, sur la base de cette recherche initiale (26 janvier):
gmsn [1.,2.,3.,4.]
gfsi [1., 1.1, 1.2]
gstn [1., 1.1,, 1.2, 1.3, 1.4]
ggpe [1., 1.1, 1.2]
ggpi [1, 1.1, 1.2]
iegpe [11, 12., 13., 14.]
iegpi [10., 11., 12.]
On observe au final que le score de maximal (14) :
* n'est obtenu obtenu que pour gstn = 1.4 et gmsn = 4. => donc pour ces deux params, pas la peine de chercher pour des valeurs plus basses
* est obtenu avec toutes les autres valeurs de gain testées => donc on peut être au plus proche de LG14 avec G=1.
* est obtenu avec toutes les valeurs de courant testées => pourrait tester quelles sont les limites basses et hautes
1.3) nouvelle grid search le 2 Février:
testedParametersIntervals['lg14modelid']=[9.]
testedParametersIntervals['gmsn']=[3.5,4.,4.5,5.]
testedParametersIntervals['gfsi']=[1.]
testedParametersIntervals['gstn']=[1., 1.1, 1.2,1.3,1.4]
testedParametersIntervals['ggpe']=[1.]
testedParametersIntervals['ggpi']=[1.]
testedParametersIntervals['iegpe']=[10.,11.,12.,13.]
testedParametersIntervals['iegpi']=[9.,10.,11.,12.]
1.4) avec le paramétrage du 1.1 (y compris les in deegree qui devraient pourtant être changés) score de 4/5 : GPi un peu trop bas (53.6 au lieu de 59 Hz) (2017_2_6_10:45_00000)
-> un test avec les 14 notes du score: 13/14 (2017_2_6_11:14_00000)
-> un test avec IeGPi 10.->11. : 14/14 (2017_2_6_11:20_00000)
Donc, le paramétrage de référence pour le modèle 9 :
gmsn=4.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=11.
iegpi=11.
-----------
optim modèle n°2
2.1) modèle 2 (il a des feedbacks non nuls du STN sur Str), 2 février:
(il y a eu aussi un test le 30 janvier, mais le code était peut-être buggé, pas sûr qu'on puisse faire confiance au résultat)
/!\ Attention, ici et en 5), on n' pas change ls "in degres" et on aurait peut-être du...
testedParametersIntervals['lg14modelid']=[2.]
testedParametersIntervals['gmsn']=[3.5,4.,4.5,5.]
testedParametersIntervals['gfsi']=[1.]
testedParametersIntervals['gstn']=[1., 1.1, 1.2, 1.3, 1.4]
testedParametersIntervals['ggpe']=[1.]
testedParametersIntervals['ggpi']=[1.]
testedParametersIntervals['iegpe']=[9.,10.,11.,12.,13.]
testedParametersIntervals['iegpi']=[8.,9.,10.,11.,12.]
AUCUN bon paramétrage !
Meilleur score de 13/14, on note que :
* ieGPE est à 13. -> tester 14. ?
* aucun des autres param n'est à une valeur extrème.
Mais certains des 12/14 on IeGPi à 8: tester 7.?
Et beaucoup ont GMSN à 5. (plus que les autres valeurs) : tester 5.5 et 6. ?
GSTN à 1.3 ou 1.4 -> 1.5 ?
2.2) modèle 2 avec mise à jour des plages de paramètres (3 février) :
testedParametersIntervals['lg14modelid']=[2.]
testedParametersIntervals['gmsn']=[4.5,5.,5.5,6.]
testedParametersIntervals['gfsi']=[1.]
testedParametersIntervals['gstn']=[1.3, 1.4, 1.5]
testedParametersIntervals['ggpe']=[1.]
testedParametersIntervals['ggpi']=[1.]
testedParametersIntervals['iegpe']=[12.,13.,14.,15.]
testedParametersIntervals['iegpi']=[6., 7., 8.,9.]
Alors, 2 param correctes :
4.50, 1.00, 1.40, 1.00, 1.00, 14.00,
4.50, 1.00, 1.40, 1.00, 1.00, 15.00
GROS BUG: on peut tout oublier sur les params du modèle 2: les seuils de décharge étaient faux (ceux du modèle 9)
2.3) Nouveaux essais avec code corrigé (LocalScript):
gmsn=4.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=10.
iegpi=10.
3/5 :
STN trop élevé (23 au lieu de 22.8)
GPi trop élevé (116 au lieu de 79)
=> baisse de gstn
2.4) baisse gSTN seulement (LocalScript)
gmsn=4.
gfsi=1.
gstn=1.2
ggpe=1.
ggpi=1.
iegpe=10.
iegpi=10.
STN trop faible ! (13.8) -> On va se concentrer sur gSTN = 1.3
GPi toujours trop élevé (105)
2.5) dernier essai en local pour définir les inervalles à explorer en grid search:
gmsn=4.
gfsi=1.
gstn=1.3
ggpe=1.
ggpi=1.
iegpe=10.
iegpi=9.
4/5 : GPi toujours trop élevé (102).
Noter que l'activité des MSN est ultra faible...
2.6) On lance donc la grid search sur (2017_2_6_14\:18):
testedParametersIntervals['gmsn']=[4.,4.5, 5.]
testedParametersIntervals['gfsi']=[1.]
testedParametersIntervals['gstn']=[1.2,1.3,1.4]
testedParametersIntervals['ggpe']=[1.]
testedParametersIntervals['ggpi']=[1.]
testedParametersIntervals['iegpe']=[10.,11.,12.]
testedParametersIntervals['iegpi']=[7.,8.,9.,10.]
------------------------------
3) le 10 février, essais sur le modèle 9 avec 8 canaux
* Avec (2017_2_10_10:10_00000):
gmsn=4.
gfsi=1.
gstn=1.3
ggpe=1.
ggpi=1.
iegpe=10.
iegpi=9.
On a:
* MSN - Rate: 0.542955748865 Hz -> OK (0 , 1)
* FSI - Rate: 9.4108490566 Hz -> OK (0 , 20)
* STN - Rate: 23.184375 Hz -> NO! (15.2 , 22.8)
* GPe - Rate: 14.298 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 31.9571428571 Hz -> NO! (59.1 , 79.5)
-------------------
******************
* Score: 2.0 / 5.0
******************
* Si on baisse GSTN à 1.2 (2017_2_10_11:23_00000), on a :
----- RESULTS -----
* MSN - Rate: 0.543125945537 Hz -> OK (0 , 1)
* FSI - Rate: 9.48679245283 Hz -> OK (0 , 20)
* STN - Rate: 16.34375 Hz -> OK (15.2 , 22.8)
* GPe - Rate: 11.338 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 30.7428571429 Hz -> NO! (59.1 , 79.5)
-------------------
******************
* Score: 3.0 / 5.0
******************
* En passant IeGPe à 11. et IeGPi à 10. (2017_2_10_11:41_00000) :
----- RESULTS -----
* MSN - Rate: 0.54359871407 Hz -> OK (0 , 1)
* FSI - Rate: 9.38632075472 Hz -> OK (0 , 20)
* STN - Rate: 15.409375 Hz -> OK (15.2 , 22.8)
* GPe - Rate: 17.503 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 37.3428571429 Hz -> NO! (59.1 , 79.5)
-------------------
******************
* Score: 3.0 / 5.0
******************
* Avec une forte baisse de GMSN (pour laisser GPe et GPi s'exprimer) (2017_2_10_11:47_00000):
gmsn=2.
gfsi=1.
gstn=1.2
ggpe=1.
ggpi=1.
iegpe=11.
iegpi=10.
----- RESULTS -----
* MSN - Rate: 0.0 Hz -> OK (0 , 1)
* FSI - Rate: 8.42877358491 Hz -> OK (0 , 20)
* STN - Rate: 12.2625 Hz -> NO! (15.2 , 22.8)
* GPe - Rate: 34.472 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 74.5375 Hz -> OK (59.1 , 79.5)
-------------------
Donc il ne faut pas trop baisser GMSN
* On remonte GMSN à 3. (2017_2_10_12:26_00000)
----- RESULTS -----
* MSN - Rate: 0.0407053706505 Hz -> OK (0 , 1)
* FSI - Rate: 8.3570754717 Hz -> OK (0 , 20)
* STN - Rate: 11.434375 Hz -> NO! (15.2 , 22.8)
* GPe - Rate: 40.089 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 71.2803571429 Hz -> OK (59.1 , 79.5)
-------------------
******************
* Score: 3.0 / 5.0
******************
* On remonte aussi GSTN à 1.3 (2017_2_10_12:33_00000)
----- RESULTS -----
* MSN - Rate: 0.0406864599092 Hz -> OK (0 , 1)
* FSI - Rate: 8.32924528302 Hz -> OK (0 , 20)
* STN - Rate: 17.296875 Hz -> OK (15.2 , 22.8)
* GPe - Rate: 42.647 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 72.6410714286 Hz -> OK (59.1 , 79.5)
-------------------
* Ca manque encore un peu de punch au niveau du GPe, on remonte IeGPe à 14 (2017_2_10_12:51_00000):
----- RESULTS -----
* MSN - Rate: 0.0406297276853 Hz -> OK (0 , 1)
* FSI - Rate: 8.14009433962 Hz -> OK (0 , 20)
* STN - Rate: 15.33125 Hz -> OK (15.2 , 22.8)
* GPe - Rate: 54.251 Hz -> NO! (55.7 , 74.5)
* GPi - Rate: 71.8321428571 Hz -> OK (59.1 , 79.5)
-------------------
* 5/5 avec (2017_2_10_12:58_00000) :
gmsn=3.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=15.
iegpi=10.
----- RESULTS -----
* MSN - Rate: 0.0407053706505 Hz -> OK (0 , 1)
* FSI - Rate: 8.00471698113 Hz -> OK (0 , 20)
* STN - Rate: 19.9625 Hz -> OK (15.2 , 22.8)
* GPe - Rate: 61.571 Hz -> OK (55.7 , 74.5)
* GPi - Rate: 72.6767857143 Hz -> OK (59.1 , 79.5)
-------------------
* =>relancé avec un test complet (15) : 2017_2_10_15:50_00000
il y avait un bug dans le calcul des taux de décharge pour les expés de déactivation, mais à première vue, le courant IeGPi n'est pas assez fort pour avoir 6Hz d'activité dans la manip AMPA+NMDA -> remonter un peu
* Test 2017_2_10_16:14_00000
gmsn=3.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=15.
iegpi=11.
10/14
Ce coup-ci, GPi trop élevé au repos, ainsi que dans certaines manips antag.
Et aussi GPe trop faible avec les antagonistes GABA (!)
=> trouver un bon paramétrage !
* Test 2017_2_13_13:32_00000
gmsn=4.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=11.
iegpi=11.
neurones CM/Pf non corrlélés (Parrot : False)
Pas le bon paramétrage, score de 2/5 sur le premier test. STN trop élevé, GPe & GPi trop bas. (au total, 5/14 !)
Il va falloir explorer pourquoi, en particulier qu'il n'y a pas de bug sur le nombre de connexions dans les modèles à canaux multiples.
3.1) Correction d'un potentiel bug dans les connections. Test(2017_2_16_10:24_00000)
5/5 OK, mais plantage à cause de la visualisation. Relancé () pour avoir le score total.
----------------------------------------------------------------------
4) A la recherche de la source de la synchronisation
Avec le petit modèle à 1 canal.
corrélés
--------------------------
CSN | N | Y | Y | Y
PTN | N | Y | N | Y
CM/Pf | N | Y | Y | N
--------------------------
Sync | N | Y | Y | N
* reproduction des résultats avec le modèle 9 (2017_2_13_11:18_00000) : OK
gmsn=4.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=11.
iegpi=11.
* virer les parrots sur les PTN (2017_2_13_11:24_00000) 14/14
les MSN semblent moins réguliers, mais les FSI toujours autant...
* virer les parrots sur les CSN et les PTN (2017_2_13_11:41_00000) 14/14
Les régularités sont là... => rôle du CM/Pf !?
=> Si oui, l'arrivée simultanée des spikes du CM/PF partout en même temps est sûrement peu réaliste, et favorise cette synchronie.
Revoir les délais des entrées du CP/Pf
* virer les parrots sur CM/Pf only (2017_2_13_12:53_00000) : 14/14
Et pas de synchronies !
Le rôle du CM/Pf sur la dynamique des BG est donc centrale...
Dans les plus gros modèles, en particulier ceux à canaux multiples, il faudra comparer les projections CMPf "diffuse" entre canaux, ou "focused". Est-ce que "diffuse" est suffisante pour se libérer des synchronies, même si on a les bons rapports de nb de neurones et des "parrots" (et donc des corrélations dans les entrées) ?
------------------------------------------------------------------------------------------
5) Premier test PD-like (2017_2_13_14:36_00000): GSTN et GGPe * 1.3 : rien de bien probant
(2017_2_13_14:39_00000) * 1.5 : pareil
=> essayer sur un réseau plus grand (là, un canal...) ?
(2017_2_13_14:42_00000) nb neurones * 10 : Là, il y a peut-être un petit quelque chose visible à l'oeil, il faudrait calculer le spectre de puissance pour y voir plus clair...
Les spectres de puissance montrent une bosse autour de beta, reste à voir si elle est là aussi en conditions normales...
Test 2017_2_14_11:20_00000 : contrôle, pour comparer.
contrôle :
OI[15-30Hz] 0.155274720822
OI[15-30Hz] 0.177146205006
DA depletion (1.5 * G[STN,GPe]):
OI[15-30Hz] 0.197807434383
OI[15-30Hz] 0.244936437859
Il y a bien une augmentation de l'index d'oscillation, tel que défini chez Kumar.
Essai avec 1.8 * G[STN,GPe]: 2017_2_14_15:5_00000
STN OI[15-30Hz]: 0.23247013906
GPe OI[15-30Hz]: 0.300145363892
------------------------------------------------------------------------------------------
6.1) Premier test de sélection avec le "Test de Gurney"
Modèle 9, CSN \in [2,10], PTN \in [15,35]
Après correction de bugs, premier essai sur les 2 premières étapes : 2017_2_17_14:31_0000
Avec 5 étapes et 2 canaux : 2017_2_17_14:52_00000
=> il n'y a pas eu de sauvegarde du fichier firingRates.csv (pas encore implémenté ?)
Relancé avec : 2017_2_22_15:21_00000
l'écriture de firingRates.csv est pê buggée, à tester...
En effet, bug, en curs de correction dans :
2017_2_22_15:35_00000
2017_2_22_16:40_00000
2017_2_23_15:5_00000
2017_2_23_15:13_00000: The good one? Proportion de neurones suractivés dans CSN et PTN : 50%
-> erreur, les canaux étaient 10x trop gros, reste des tests taillex10.
On relance : 2017_2_23_15:46_00000 (2 canaux)
Sur la première étape, l'un des canaux est un peu trop bas, donc le score ne test ne passe pas.
58.9285714286 Hz 61.5178571429 Hz NO!
Avec proportion d'actifs de 0.2 (2 canaux) : bug ? C'est très louche, les activités sont strictement identiques en sortie !
trouvé et corrigé : 2017_2_23_16:3_00000 !
Toujours 4/5 car sortie GPi un peu faible : augmenter Ie_GPi ?
6.2) Gurney en Local :
* 2017_2_23_16:53_00000, 2 canaux, PActPop=0.2
gmsn=4.
gfsi=1.
gstn=1.4
ggpe=1.
ggpi=1.
iegpe=11.
iegpi=12.
OK !
* 2017_2_23_16:59_00000, 2 canaux, PActPop=0.5
OK, on atteint déjà la sur-sélection : GPi = (0,0) pour (0.4, 0.6)
* 2017_2_23_17:3_00000, 2 canaux, PActPop=1.
OK, on atteint déjà la sur-sélection : GPi = (0,0) pour (0.4, 0.6)
* 2017_2_23_17:5_00000, 8 canaux, PActPop=1.
OK, on atteint déjà la sur-sélection : GPi = (0,0) pour (0.4, 0.6)
* 2017_2_23_17:11_00000, 8 canaux, PActPop=0.5
OK, on atteint déjà la sur-sélection : GPi = (0,0) pour (0.4, 0.6)
* 2017_2_23_17:18_00000, 8 canaux, PActPop=0.2
6.3) Lancé sur Sango avec 2 (2017_2_17_15:41_00000) puis 8 canaux (2017_2_17_17:31_0000).
sur 2017_2_17_17:31_0000: apparemment, problème d'écriture des fichiers car trop de fichiers ouverts.
Relancé avec seulement 8 cpu : 2017_2_21_11:34_00000 (core dumped!)
Relancé 2017_2_22_11:55_00000
Par ailleurs, STN très élevé, sélection trop forte (sortie canal 1 à 0 alos que canal 1: 0.4 et canal 2: 0.6). travailler les plages de variation de CSN et PTN (pour l'instant, CSN: 2-10, PTN: 15-35), et aussi sur des variations du nombre d'inputs qui atteignent ces valeurs (actuellement 100% des neurones d'entrée d'un canal activés identiquement).
------------------------------
Reminder NEST:
Paramètres du iaf_psc_alpha_multisynapse
{u'type_id': <SLILiteral: iaf_psc_alpha_multisynapse>,
u'elementsize': 712,
u'vp': -1,
u'synaptic_elements': {},
u'V_reset': -70.0,
u'supports_precise_spikes': False,
u'tau_syn': (),
u'tau_minus': 20.0,
u'tau_m': 10.0,
u'capacity': (1000,),
u'I_e': 0.0,
u'instantiations': (1,),
u't_spike': -1.0,
u'V_m': -70.0,
u'local': True,
u'recordables': (<SLILiteral: currents>, <SLILiteral: V_m>),
u'E_L': -70.0,
u'available': (999,),
u'node_uses_wfr': False,
u'V_th': -55.0,
u'tau_minus_triplet': 110.0,
u'n_synapses': 0,
u'thread_local_id': -1,
u'beta_Ca': 0.001,
u't_ref': 2.0,
u'thread': 0,
u'frozen': False,
u'archiver_length': 0,
u'Ca': 0.0,
u'C_m': 250.0,
u'global_id': 0,
u'element_type': <SLILiteral: neuron>,
u'has_connections': False,
u'model': <SLILiteral: iaf_psc_alpha_multisynapse>,
u'V_min': -inf,
u'tau_Ca': 10000.0}