I was about to mention swig-fortran myself. FYI, the project was started by a guy named Seth Johnson at Oak Ridge National labs and his co-workers. I think they have papers and reports available on-line. Probably a web search on “Seth Johnson ORNL SWIG Fortran” will give you several hits. Also, I’ve decided to try my hand at generating a SISL C-interop package of my own as an after hours project. I think it will take me about a week to just generate the code for the interfaces and another month or two to write enough unit tests to verify they work. I hope to get back to doing some Isogeometric Analysis work in the future so having fairly complete NURBS package will help so my time won’t be wasted. I’ll keep you posted here.
As @vgmangin implied, the problem with projects like this is you try to start out small and just implement the things you think you need but soon you find you are implementing many more functions sometimes just to see if you can do it. My first experience with C-interop was in the 2005-2006 time frame when it was still in its infancy in most compilers (meaning I had to come up with a lot of workarounds for compilers that were still having problems getting it right). I was trying to port some DOE code (the EXODUS finite element data base software) to Cray’s last attempt at classic Cray X-MP, Y-MP style vector machines (I think it was called an X1 or XV1). EXODUS sat on time of the UCAR NetCDF package which did the actual file IO. Cray for some reason kept 64 bit integers as the default for the Fortran compiler but let the C compiler be standard ANSI C (an int was 32 bits). This made getting data from the Fortran compiler down to the C code used by netCDF an exercise in futility. netCDF’s Fortran interfaces were C wrappers generated by the cfortran.h macro package. I decided as a learning exercise to try to implement C-interop interfaces since the Cray compiler supported them along with g95 and the IBM compiler. The next thing I know (5 years later) I had an almost complete set of interfaces to netCDF. I offered the code to UCAR and its now part of the mainline netCDF Fortran interfaces. Again, my original intent was just a proof of concept learning exercise. Somehow it got out of hand but I did learn a lot (more than I intended). Maybe one of these days I’ll write a paper or a monograph on lessons learned. Also, inspired by a paper I read many years ago about the similarities and differences of Finite Element and Finite Volume methods used in CFD and structural dyamics titled Finite Elements and Finite Volumes: Two “good” friends, I think I’ll title it Fortran and C: Two “good” friends who get into heated arguments and occasional fist fights.
I have used the Dierckx’s library successfully. It is fairly limited in scope, but it did what I needed and it was well-documented. Available here: DIERCKX
It has a few quirks, but not being a Computational Geometry guy, I didn’t want to take the time to learn any more advanced (read: complicated) library. (I still don’t know what a NURB actually is…)
Is there anything inherently lacking in Fortran to be not used in Computational Geometry (CG)? I see mostly ‘C’ being used. Is it because there was no ‘derived type’ in Fortran at that time ? Irregular data structures are difficult with arrays. But now with derived types we can petty much do everything what ‘C’ can do. I don’t know if any other low level control is required for CG. Does anybody foresee any problem with Fortran in this field ?
In my wiew with the actual OOP features Fortran can do a looot more than C. I’m working on some small/medium (~20k/40k lines) CG Fortran OOP projects and I really lack nothing from this perspective. I’d spend more time learning useless OOP feature than implementing algorithm if I’d used C/C++.
I liked that you have put ‘ooo’ in looot. Then lets start. My goal is to implement first NURBS in Fortran then start Isogeometric Analysis library that uses NURBS.
By the way I found the implementation of Piegl’s book codes in Fortran here - Bitbucket
He coded in Fortran and then interfaced to python using f2py. But it will be difficult to progress further in python because it is numerically intensive. I think Fortran will be best choice here.
Let’s not consider python interfacing now. It is Fortran that has the need for a nurbs library… I think that for such a big task at least 3/4 developers are needed…to not end like other Fortran nurbs libraries… incomplete and abandoned after 1 year of work…
Is there a good C or C++ library for nurbs? I am considering writing a subset of C++ to Fortran translator, so we could translate such libraries automatically.
I admit my noviceness in this field. But we are not implementing full CG - like CGAL or something right? NURBS should be a small project. I don’t know what you have in mind - sorry - you may want to explain.
Moreover once we start people may join - when we publish our work in some good journal - we can write about it’s functionality and use cases in our specific domains - then people may join. We can create some basic running version - use it in our domains and then people may join.
We have to write a good documentation for uses and developers. Unfortunately many open source libraries are developed nicely, but documentation is very poor - even for users, forget about developers.
I my field of Computational structural mechanics - especially Iso-geometric Analysis there is no such library available in Fortran. People are currently interfacing some NURBS -‘c’ libraries (Piegl’s) with Matlab and are stopping at some point because of - I think scalability and speed issues. Fortran has speed and simple understandable syntax similar to Matlab - so I think it should work.
We can give a try. Small or big depends on the features you want to implement…for example, nurbs-nurbs intersection can lead to a big project. However let’s try. Maybe a good idea can be to start a new topic to advertise the need for developers here on Fortran lang.
@Ashok, no need translate SISL from C. See my Fortran-C interop interfaces that I developed in response to the original OP in this thread.
Also, I actually started developing my own NURBS package in native Fortran several years ago (almost 12 years ago now) to support IGA but put it aside due to lack of time and funding. Its about 50% complete. I’m planning on retireing sometime in the next 8 months or so and will probably revisit it then.
Also several, Python based IGA codes had supporting Fortran implementations of the basic NURBS capability etc you need for IGA. See
My Fortran implementation was focused on implementing as many of the algorithms outlined in Piegl and Tiller’s, NURBS book as possible. My code is still a little too rough and untested for general release. Besides, for the basic support you need for IGA, the Pigasus code as well as the igalib.f90 file from
give you the basic NURBS capability you need to do the FEM part of IGA. However, a more full blown CAD like package is probably needed to handle general geometry and thats whats missing in my code. As @Rob777 has noted that is a major software development project that will take a serious investment in time and money.
I’ll try to start cleaning up my code and will release it in increments when time permits but that might be several months from now.
@Rob777, Unfortunately the version of DT_NURBS on the cfdtools repository was not the last official release version which was distributed by Boeing Computer Services for David Taylor Research Center. There might be someone at David Taylor you could contact to get a more recent version but I think BCS probably added code they consider proprietary to Boeing so I doubt it can be released outside the Gov’t. There is a manual somewhere on the web (forgot where now) that describes a more recent version and appears to define more functions than the NASA version. SISL is not officially maintained but its used in the SINTEF GoTools code that replaced it so it will be around for a while. GoTools is C++ and while creating Fortran interfaces for the code is doable, it takes another level of effort beyond the C based interfaces in SISL.