Bonjour à tous,

J'ai un projet personnel qui me tient à cœur depuis une dizaine d'années, celui de travailler sur un projet open source associé au génie civil.

Vous avez des besoins ? Vous râlez tous les jours sur vos feuilles Excel et leurs macros ? Ce post est fait pour vous

 

En 2012, j'avais réussi à développer les bases d'un logiciel de modélisation aux éléments finis. Si vous voulez, vous pouvez voir une démonstration "Home made" sur Youtube. Pardonnez les pixels

Malheureusement, j'avais dû abandonner car c'était un projet d'une trop grande ampleur. De plus, je m'étais un peu trop isolé pour le faire ce qui avait fini par nuire à ma motivation.

Depuis de l'eau a coulé sous les ponts. J'ai compris la nécessité de répondre d'abord aux besoins des utilisateurs avant les miens . J'ai aussi acquis une solide expérience professionnelle en informatique. Surtout, je suis toujours aussi motivé qu'il y a 10 ans autour de ce projet.

 

 

Maintenant, je suis à la recherche de personnes (peut-être toi, cher lecteur) qui partagerait mon enthousiasme. Je suis ouvert à tout projet.
 

L'objectif serait de savoir si vous avez besoin d'outils ou de logiciels informatiques appliqués dans le génie civil. Ma spécialité est la structure mais si vous donnez suffisamment de détails, je peux concevoir n'importe quoi (on va dire ça pour ne brider la créativité de personne).

Le monde du génie civil s'est beaucoup digitalisé depuis le passage au BIM. Malgré cela, je trouve qu'il existe peu d'initiatives dans le génie civil autour du milieu open source.

Donc si vous avez des idées, partagez les

 

Le projet doit avoir les caractéristiques suivantes :
  - être en lien avec votre travail dans le génie civil,
  - être opensource,
  - être d'une taille modeste. Je ne ferai pas un concurrent à Arche ou SCIA. Mais des utilitaires plus spécialisés comme ceux du CTICM/ArcelorMittal sont envisageables.
  - vous avez un peu de temps à consacrer pour me dire vos besoins et suivre l'avancement du développement,
  - il sera développé gratuitement sur mon temps libre. Oui, le développement de logiciels et le génie civil sont ma passion. Par contre, je ne vous promets pas un développement sous 3 mois

 

A vos claviers maintenant

Il y a 21 heures, bansan a dit :

@BELLAMINEC'est une belle idée. C'est vrai que le dimensionnement des fondations superficielles est complexe. Il y a de nombreuses méthodes de reconnaissance de sol et autant de méthode de calculs.
Je me souviens aussi d'une méthode de l'ITBTP qui détaillait comment calculer la surface comprimée. Mais je n'arrive pas à retrouver la feuille de calcul ni la référence  .
J'ai un peu parcouru le long fil, je vois qu'il y a de nombreuses "fiches de progrès". Ça me permettrait aussi de me replonger dans l'Eurocode 7 qui est comme les autres Eurocode un sacré pavé... Ce sont ces fiches que tu proposerais d'implémenter ?

Bonjour à tous

Les fiches de progrès ont été élaborées dans le cadre d'une étude de comparaison entre le fascicule 62 titre V et EC7, pour le dimensionnement des fondations superficielles pour bâtiments et autres.  C'est le contexte méthodologique (discutable) de dimensionnement des fondations superficielles, qui découle de cette étude comparative qui importe !!!

La démarche méthodologique pour ce projet, comment je la vois personnellement est comme suit :

Faire d'abord le bilan des besoins en utilitaires ou si vous voulez modules ou cellules interactives pour un projet (bâtiment, ouvrage d'art, etc ...). Certains utilitaires peuvent servir pour des projets de nature différente. Par exemple un utilitaire "fondations superficielle" pourra servir pour le cas des bâtiments, que celui des ouvrages d'art ... Donc ces utilitaires devront être flexibles et interactifs à toute demande ou appelle directe ou en arrière plan. Ils auront donc une double fonctionnalité. Une fonctionnalité d'utilisation directe et indépendante et l'autre dans le cadre d'un logiciel pilote qui va gérer l'interaction en arrière plan entre les différents utilitaires pour répondre aux besoins d'étude d'un projet.

Personnellement, je prend l'engagement pour contribuer au présent sujet sur le plan technique et algorithmique sous forme de fiche de progrès. En informatique, c'est l'architecture de l'interface utilisateur qui prend beaucoup de temps.

Cordialement        

 

@BELLAMINE Je te remercie de ta proposition et pour ton souhait d'implication. Je vois que tu as déjà une bonne idée de ce que tu veux obtenir. Tes documents serviront également de bonne base technique. C'est une bonne chose  Je mets de côté ton idée.

 

J'attends de voir si d'autres personnes ont des idées précises et si elles souhaitent s'impliquer. Je suis bien conscient que cet engagement peut faire un peu peur. Il faudra juste un peu de temps au début, le temps de définir précisément quelles fonctionnalités. Ensuite, ça devrait être de tester le logiciel deux fois par mois pour vérifier que l'avancement va dans le bon sens.

 

Et puis, les outils auront tous la même base technique. Donc rien n'interdit de prendre deux projets (à voir quand même...) puisque c'est à mon avis l'architecture informatique et l'interface graphique qui prendront le plus de temps. La partie purement technique "génie civil" devraient poser moins de problème (enfin, j'espère...  )

Bonsoir @bansan,

attention tout de même le javascript comporte quelques limites :

• les temps de calculs peuvent être longs, voire même très longs, en fonction de la complexité des calculs et en fonction du navigateur utilisé. Je programme mes utilitaires en javascript et je suis souvent obligé de limiter les itérations. J'ai fait par exemple un petit utilitaire qui calcule le tassement d'une dalle souple avec la méthode de Steinbrenner et qui produit une image 2D de la plaque colorée en fonction du tassement => avec Chrome, le temps de calcul peut atteindre 30 secondes d'attente pour l'utilisateur !...et le même calcul va nécessiter 50 secondes sous Firefox et plus d'une minute avec EDGE ou Internet Explorer !
• par ailleurs le javascript est monoprocessus...impossible d'afficher une barre de progression à l'écran pendant que l'ordinateur de l'internaute calcule,
• je développe actuellement un petit logiciel de stabilité de talus basé sur la méthode de Bishop...tout fonctionne bien sur ma machine avec plein de mémoire vive et Chrome (temps de calculs presque instantané) mais dès que je passe sur un ordi classique ça devient plus compliqué en termes de temps d'attente ...donc pour pouvoir le mettre en ligne, je passe un temps fou à "alléger" le code et à optimiser les algorithmes => et finalement, je vais peut être devoir le retraduire en php et confier le calcul au serveur plutôt qu'à l'ordinateur de l'internaute,
• pour le dessin et les graphiques, je te conseille d'éviter les bibliothèques toutes faites, certes très pratiques, mais distribuées sous des licences très restrictives. Avec le HTML5 et les balises <canvas> on peut assez facilement faire des graphes et des dessins très corrects.

Bref...pour de petits programmes simples du genre application d'une formule analytique, le javascript fonctionne bien, par contre pour des applications plus complexes, avec de nombreuses boucles et itérations, c'est pas ouf ! 

Cordialement

Merci du conseil. C'est vrai que je n'ai jamais développé d'applications de calcul en JavaScript. Mais je suis étonné des mauvaises performances dont tu me parles. Je croyais que le web assembly (tout le JavaScript est maintenant converti en direct par les navigateurs avant d'être exécuté) était devenu très performant.

Ma spécialité est plutôt le back. Mais j'ai côtoyé pendant deux ans des développeurs front. Leur technique pour mettre à jour l'interface graphique était que tout passe par une web socket. L'utilisateur clique sur un bouton ? Événement envoyé à la web socket qui met à jour l'interface graphique. Donc, je devrais pouvoir mettre ainsi à jour l'interface graphique même si JavaScript ne rend pas la main. Merci du conseil, je testerai ce point particulier.

L'utilisation des framework, c'est surtout pour faciliter l'utilisation d'effets visuels pour que l'interface fasse "moderne". En fonction de la simplicité des dessins à générer, c'est effectivement possible qu'un simple canvas suffise.

Envie merci pour tes retours. C'est aussi pour ça qu'il faut que je développe en séparant bien les fonctionnalités : pour éviter qu'un mauvais choix technique ne deviennent irréparable. J'ai quelques contacts de personnes faisant exclusivement du front. Peut-être accepterons-t-ils de m'aider dans les choix techniques.

Message supprimé car contenu complètement faux...

Modifié Mars 19, 20214 a par bansan

Il y a 12 heures, bansan a dit :

Merci du conseil. C'est vrai que je n'ai jamais développé d'applications de calcul en JavaScript. Mais je suis étonné des mauvaises performances dont tu me parles. Je croyais que le web assembly (tout le JavaScript est maintenant converti en direct par les navigateurs avant d'être exécuté) était devenu très performant.

Ma spécialité est plutôt le back. Mais j'ai côtoyé pendant deux ans des développeurs front. Leur technique pour mettre à jour l'interface graphique était que tout passe par une web socket. L'utilisateur clique sur un bouton ? Événement envoyé à la web socket qui met à jour l'interface graphique. Donc, je devrais pouvoir mettre ainsi à jour l'interface graphique même si JavaScript ne rend pas la main. Merci du conseil, je testerai ce point particulier.

L'utilisation des framework, c'est surtout pour faciliter l'utilisation d'effets visuels pour que l'interface fasse "moderne". En fonction de la simplicité des dessins à générer, c'est effectivement possible qu'un simple canvas suffise.

Envie merci pour tes retours. C'est aussi pour ça qu'il faut que je développe en séparant bien les fonctionnalités : pour éviter qu'un mauvais choix technique ne deviennent irréparable. J'ai quelques contacts de personnes faisant exclusivement du front. Peut-être accepterons-t-ils de m'aider dans les choix techniques.

Bonjour 

Vous trouverez peut-être des réponses liées aux difficultés de programmation informatique et choix du langage de développement approprié à vos besoins en s'inscrivant sur le site ci après :

www.developpez.com

Cdlt 

 

@BELLAMINE Merci pour le lien. En fait, il y a tellement de façons différentes de faire qu'il y a de bons choix. Il faut choisir une technologie compatible avec le projet.
J'avais essayé de faire des comparatifs entre un code en C++ et un code en Javascript mais je me suis complètement trompé dans les calculs. Si on se rend compte que la partie moteur est vraiment trop lente en convertissant le code C++ en javascript, on pourra faire tourner une application serveur à la place. C'est l'intérêt de coder cette partie avec un maximum de portabilité.

@BELLAMINE Je vais faire quelques recherches cette semaine pour éclaircir certains points techniques. J'ai vu que tes fiches sont déjà bien détaillées. Est-ce que tu pourrais préparer et m'envoyer une des fiches que tu voudrais que j'implémente ? Ça me permettra de réfléchir à la conception de l'architecture du code. Merci.

Il y a 3 heures, bansan a dit :

@BELLAMINE Je vais faire quelques recherches cette semaine pour éclaircir certains points techniques. J'ai vu que tes fiches sont déjà bien détaillées. Est-ce que tu pourrais préparer et m'envoyer une des fiches que tu voudrais que j'implémente ? Ça me permettra de réfléchir à la conception de l'architecture du code. Merci.

Bonjour

Voir l'onglet téléchargement sur ce site. Il y a beaucoup de choses intéressantes partager par nos confrères ingénieurs qui pourrons vous être utiles pour ce projet.

A titre d'exemple ci après un lien d'un mémento pour fondations superficielles selon EC7. 

Je ne sais pas quelles fiches en sus vous voulez que je prépare en plus des fiches de progrès que j'ai partagé. Le principe est le dimensionnement des fondations superficielles en partant des données géotechniques sans faire appelle à l'ancienne méthode qui se base sur une valeur dite "Contrainte admissible d'un sol" et qui pourrai dans certains cas (Vent et Séisme) induire en erreur le processus de dimensionnement conformément à la réglementation en vigueur.  

Cdlt  

Modifié Mars 21, 20214 a par BELLAMINE

Merci pour le mémento.

En fait l'idéal ça serait d'avoir une liste exhaustive des paramètres d'entrée et quels résultats on doit avoir.

Par exemple : l'utilisateur devra saisir les efforts pour un seul cas de charges ou plusieurs ? les efforts seront cumulés à l'elu / els ou les valeurs sont non pondérés et c'est le logiciel qui fera la pondération ? Dans un premier temps, je ferai pour une valeur précise à ELU / ELS mais que faire à terme ?

Dans le mémento, il y a les explications pour calculer le qnet depuis les essais pressiometriques. Faut-il le prévoir ou l'utilisateur saisit directement le qnet ? À priori, je dirais que ça n'est pas nécessaire puisque le but est de "en partant des données géotechniques". Est-ce le cas ?

Je n'ai pas encore regardé les feuilles de progrès en détail.