Existe-t-il un ensemble open source de solveurs ODE pour C qui utilisent le type complexe natif C99?


12

J'ai utilisé GSL comme base de plusieurs de mes simulations, mais c'est un peu exagéré pour mes besoins et il définit son propre type complexe pour des raisons héritées. Plutôt que de coder mon propre solveur Runge-Kutta ODE, qui ne serait probablement pas très efficace, existe-t-il des solveurs ODE open source qui utilisent le type complexe natif C99?


Je ne sais pas où voulez-vous l'utiliser, mais en général RK est assez difficile à implémenter de manière non efficace ... Avez-vous fait des tests de performance qui ont montré que vous avez ce problème?
mbq

2
Aucun. Je n'ai pas écrit le mien parce que je ne veux pas réinventer la roue. Si je le dois, je le ferai, mais trouver du temps à consacrer à quelque chose qui n'est pas cassé n'est pas prévu pour moi en ce moment. Si une réponse arrive, c'est ce que je cherche, je ne pourrai pas l'utiliser si pendant quelques mois. De plus, RK n'est pas toujours ce dont j'ai besoin, juste ce pour quoi je connais l'algorithme.
qubyte

Soit dit en passant, je fais la plupart du temps des simulations de petits systèmes quantiques. Pas exclusivement cependant.
qubyte

Je déconseille de mettre en œuvre vous - même un RK de taille variable (sauf à des fins éducatives). Il y a beaucoup d'heuristiques impliquées dans la recherche de la taille de pas optimale.
Jitse Niesen

Comme je l'ai dit, tout ce que j'écrirais rapidement serait soit faux, soit lent. Est-il particulièrement difficile d'implémenter RK avec des entrées / sorties complexes? Je sais que vous pouvez simplement le diviser en deux parties réelles, mais c'est un peu ennuyeux!
qubyte

Réponses:


10

Vous pouvez le considérer comme "excessif", mais le package d'intégration temporelle de PETSc peut être utilisé avec C99 complex (configure --with-scalar-type=complex). Les méthodes prises en charge incluent

Ces implémentations sont les plus appropriées pour les problèmes de grande dimension tels que les équations différentielles partielles semi-discrétisées (méthode des lignes).


C'est un peu grand, mais je ne le savais pas alors +1. Idéalement, tout ce que j'utilise ne sera pas plus grand que GSL. Je vais jeter un œil au manuel et voir ce que je pense.
qubyte

Juste pour être clair, vous créez un lien avec ces bibliothèques au moment de la compilation. Est-ce correct?
qubyte

Rien n'est lié au moment de la compilation. Déjà. La liaison est effectuée après la compilation (même si le compilateur appelle l'éditeur de liens). Vous pouvez charger dynamiquement la bibliothèque, mais vous aurez besoin des en-têtes pour compiler votre code à appeler dans la bibliothèque. Si cela ne répond pas à votre question, veuillez expliquer ce que vous voulez faire.
Jed Brown

Vous avez bien sûr raison. Erreur idiote, mais vous saviez ce que je voulais dire. Ma question aurait été mieux formulée comme "Dois-je créer un lien vers ces bibliothèques?" par opposition à la compilation des bits dont j'ai besoin en même temps que mon propre code comme c'est le cas avec Boost. Je suis conscient que l'appel de fonctions à partir d'une bibliothèque nécessitera des en-têtes, je le fais depuis un certain temps.
qubyte

Oui, vous compilez PETSc indépendamment de votre application. Ce n'est pas uniquement l'en-tête comme Boost.
Jed Brown du

1

Une autre option que vous avez, à moins que le système ne soit plutôt compliqué, consiste simplement à convertir d'une notation complexe en un problème avec deux inconnues qui représentent la partie réelle et imaginaire. Vous pouvez ensuite utiliser un solveur ODE à valeur réelle standard.


C'est exactement ce que j'essaie d'éviter. En fait, les intégrateurs GSL ne sont réels que si la mémoire est bonne, c'est donc ce que je fais en ce moment.
qubyte
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.