The software was last changed in 2017 and doesn't compile against current libraries. I am considering a fork but only if this project has been dropped by the authors. Is this the case?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi honestguvnor. The project is still active, even if the current distribution is pretty old. The development is now followed by Lorenzo Burghignoli e Giorgio Palma, two of my collaborators. They have developed a newer version with major improvements of the formulation, including new regularization techniques and the possibility to include moving sources and scatterers. I don't know when they plan to release the new version. BTW, the code compiles and runs well also against current version of libraries, with few minor changes of the procedures.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply. When I didn't get a response after a few days I started fixing the code. Replaced autotools (which is complicated and wasn't working) with a few lines in cmake files which then built on linux and windows, fixed the globals/extern (I have no idea how the code ever compiled?), fixed the deprecated and removed mpi part, added python driver, minor fixes for windows platform, plus likely one or two other minor things. The code then ran on current linux and windows platform (and possibly mac but I no longer have a mac) but would fail (needlessly) trying to open too many files at once for a frequency sweep and valgrind was still reporting a number of issues.
I had then been intending to refactor the code to give it a more reasonable source structure, more appropriate file interaction and move out what is better handled in upstream or downstream scripts/programs. However, when I looked more closely at would be modified it was clear there would be little if anything left of the original code. I should of course have done this initially but too much haste less speed. So instead I started from scratch with a simple basic BEM code in the style of a teaching code with constant triangular or quadrilateral elements, gauss/duffy quadrature, scalapack,,... which I am currently minimally documenting and testing prior to posting on github (or equivalent). With luck should happen in a few days.
I am happy to make the partially fixed acousto-2.0 code available if anyone would like to continue and remove the remaining issues. Although the code runs and is likely producing correct output (it looks plausible but I haven't checked) the remaining issues ought to be fixed before releasing. If a more developed acousto is soon to be released then it probably isn't worthwhile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We appreciate your effort, and the fact that you make it available. The problem that I see is that the acousto project is an academic project that follows a strict and rigorous scientific approach in implementing an original BIE formulation. Even if the current released version is limited to static acoustics, it is part of a much more complex code developed throughout the last three decades. The formulation used in acousto is not standard and presents a number of peculiarities in many aspects of the formualtion, like the management of sources and primary field, the regularization, the analytical integration (acousto doesn't use quadratures), the possibility to be interfaced with external aerodynamic solvers , etc. One of the reason why we are taking so much time to release the 2.5 version is that the validation in presence of major modification of the code is extremely long. It's not only a matter of reproducing the test cases provide with the distro, but check carefully the rate of convergence of the solution and the effectiveness of the regularization technique. Some of the issues you have fixed are already fixed in the 2.5 version, but other major changes shoud be discussed and approved before proceeding to the implementation. If you want to join the development team, we can certanly talk about it, maybe using the private email.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My interest is an easy to understand and use "teaching" BEM code to be developed in the open. I had initially been considering forking and modifying acousto for this purpose if the project was dead. Since it is not dead I have no wish to fork it and I would guess the current group of developers have no wish to have their code substantially reworked to serve my purposes (I sure wouldn't!). Anyway, as mentioned above, I changed direction and put together the bulk of a basic BEM code last week and although distracted by other things at the moment hope to get back to it in a few days and finish it off.. Good luck with the further developments of acousto and I look forward to running version 2.5 when it is released.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The software was last changed in 2017 and doesn't compile against current libraries. I am considering a fork but only if this project has been dropped by the authors. Is this the case?
Hi honestguvnor. The project is still active, even if the current distribution is pretty old. The development is now followed by Lorenzo Burghignoli e Giorgio Palma, two of my collaborators. They have developed a newer version with major improvements of the formulation, including new regularization techniques and the possibility to include moving sources and scatterers. I don't know when they plan to release the new version. BTW, the code compiles and runs well also against current version of libraries, with few minor changes of the procedures.
Thanks for the reply. When I didn't get a response after a few days I started fixing the code. Replaced autotools (which is complicated and wasn't working) with a few lines in cmake files which then built on linux and windows, fixed the globals/extern (I have no idea how the code ever compiled?), fixed the deprecated and removed mpi part, added python driver, minor fixes for windows platform, plus likely one or two other minor things. The code then ran on current linux and windows platform (and possibly mac but I no longer have a mac) but would fail (needlessly) trying to open too many files at once for a frequency sweep and valgrind was still reporting a number of issues.
I had then been intending to refactor the code to give it a more reasonable source structure, more appropriate file interaction and move out what is better handled in upstream or downstream scripts/programs. However, when I looked more closely at would be modified it was clear there would be little if anything left of the original code. I should of course have done this initially but too much haste less speed. So instead I started from scratch with a simple basic BEM code in the style of a teaching code with constant triangular or quadrilateral elements, gauss/duffy quadrature, scalapack,,... which I am currently minimally documenting and testing prior to posting on github (or equivalent). With luck should happen in a few days.
I am happy to make the partially fixed acousto-2.0 code available if anyone would like to continue and remove the remaining issues. Although the code runs and is likely producing correct output (it looks plausible but I haven't checked) the remaining issues ought to be fixed before releasing. If a more developed acousto is soon to be released then it probably isn't worthwhile.
We appreciate your effort, and the fact that you make it available. The problem that I see is that the acousto project is an academic project that follows a strict and rigorous scientific approach in implementing an original BIE formulation. Even if the current released version is limited to static acoustics, it is part of a much more complex code developed throughout the last three decades. The formulation used in acousto is not standard and presents a number of peculiarities in many aspects of the formualtion, like the management of sources and primary field, the regularization, the analytical integration (acousto doesn't use quadratures), the possibility to be interfaced with external aerodynamic solvers , etc. One of the reason why we are taking so much time to release the 2.5 version is that the validation in presence of major modification of the code is extremely long. It's not only a matter of reproducing the test cases provide with the distro, but check carefully the rate of convergence of the solution and the effectiveness of the regularization technique. Some of the issues you have fixed are already fixed in the 2.5 version, but other major changes shoud be discussed and approved before proceeding to the implementation. If you want to join the development team, we can certanly talk about it, maybe using the private email.
My interest is an easy to understand and use "teaching" BEM code to be developed in the open. I had initially been considering forking and modifying acousto for this purpose if the project was dead. Since it is not dead I have no wish to fork it and I would guess the current group of developers have no wish to have their code substantially reworked to serve my purposes (I sure wouldn't!). Anyway, as mentioned above, I changed direction and put together the bulk of a basic BEM code last week and although distracted by other things at the moment hope to get back to it in a few days and finish it off.. Good luck with the further developments of acousto and I look forward to running version 2.5 when it is released.