Merci pour cet update, qui du coup m'a fait découvrir qu'il existait un tuto pour les éléments finis.
J'aimerais commenter plusieurs points.
1)
Le problème est que pour Python, la division d'un entier donne un entier (division euclidienne). Pour le forcer à considérer i comme un réel, on lui convertit explicitement i en réel en appelant float(i).
Ceci dit, depuis l'arrivée de Python 3, il y a quand même eu quelques évolutions...
2) A ce même endroit, pourquoi faire remplir le tableau valeur par valeur comme ça :
1 2 3 4 5
| # Maillage
# Generation de la table coor
coor = np.zeros((ne+1,1)) # Initialisation
for i in range(ne+1):
coor[i,0]=(float(i)/(ne))*L |
alors qu'on a np.linspace ou bien np.arange, qui sont beaucoup plus performant ?
3)
1 2 3 4
| # Prise en compte des CL
Kii = np.delete(K,0,0)
Kii = np.delete(Kii,0,1)
Fi = np.delete(F,0,0) |
Pourquoi faire des delete ? Pourquoi ce double stockage ? Dans un cas général, cela va être une très grosse matrice. Il semble donc raisonnable d'en éviter la copie.
Peut-être est-ce pour réduire la taille du système vu que l'on connait la donnée au bord (ce que je présume), on l'enlève du système et on la rajoute après résolution du système. Mais ca reste moins rentable avec ces copies et ces réallocations que cela engendre. Et de plus si on a un autre type de condition limite, avec cette technique, on est coincé.
Pourquoi ne pas directement construire une matrice qui ait, d'emblée, la même taille que le maillage, quitte à en updater la première et la dernière ligne si la condition limite l'exige et à ne travailler qu'avec cette matrice ?
2 |
0 |