Home Download News Features Screenshots Documentation Communicate Participate Resources Applications Site Map
The questions:
I found a bug, what should I do?
Why I cannot load my microscope files?
Why C programming language?
Why to use Gtk+ library?
Can I use my own routines with this software?
What about portability to other systems?
Could we use commercial plug-ins?
When it will be finished?
Can I use other graphical library (Qt, MFC) with the program
Why Gwyddion?
Will my plug-ins work with future versions of
Gwyddion?
Will my modules work with future versions of
Gwyddion?
When a new version will be released?
How can I get notified of new releases?
What systems and architectures Gwyddion runs on?
What the strange PSDF values mean?
How do I send large data files to you, do you have a FTP upload area?
I linked Gwyddion with --as-needed and it broke. How to fix it?
Please, report it to Petr.
Also please check it is still present in the latest stable version. You will be likely asked to upgrade if you report a bug in an old version.
For file loading-related bugs please provide the file that causes problems to make reproducing the bug easier. If you experience crashes on a Unix-based system a gdb trace or valgrind output will also be helpful for locating the bug.
If your microscope native files are not supported yet, you can write a IO plugin by yourself or you can contact us and send us your format specifications and some data.
If your format is supported but you have problems with file loading, report it as a bug (we will need the problematic file to fix it).
There is page describing the file format situation in details.
The core and modules is written in C language.
This language was chosen as it is well known and widely spread, there are many important libraries that could be used (Gtk+), and it's relatively easy to bind C function to other languages. The plugins can be written in C, C++, Perl, Python and maybe more. The simplest ones can be written in almost any language.
The Gtk+ graphical library is used because of its licensing, portability and capabilities.
Yes, you can make a plug-in very easily from your software. This is one of the main goals.
Roughly said, you just need to use the specified data recieveing and sending back to the program. Then you can use your software routines as a plug-in inside the program. If you want, you can take more time programming it as a module so that everybody will be able to use your functions.
The high portability will be respected within the core and modules. The system will be developed and tested under Windows and GNU/Linux operating systems but all the libraries can be used also in many more systems. Therefore it can be ported relatively easily.
Yes you can. You can use a plug-in with other than open source license. However, such a plug-in can't be official part of the program, but can be distributed separately.
As the system should be framework for developement and share of new analytical methods, everlasting continuous developement is expected.
Yes you can do it in a form of simple plug-ins. But note, that with using some libraries (MFC) you may produce code that is not portable. This is not problem if you use code for you own, but you might be in a problem when you want to share your plug-in with someone.
Please see explanation.
Yes, virtually forever.
Even if a decision was made the current plug-in system is so bad that a new one must be designed, Gwyddion architecture would allow the old and new plug-in system to coexist, and the current would be kept for compatibility with existing plug-ins.
Note: The plug-in system is considered ill-designed. While this does not mean the plug-in support will disappear soo, certainly it will not disappear before Gwyddion 3.0, it is not the preferred method to add routines in other programming languages any more and it cannot be expected to be further developed. Better alternatives can be language bindings, such as pygwy, or writing a small C wrapper module specific for your language and problem domain, i.e. a kind of small specialized plug-in proxy that interfaces your routines the way you prefer.
Yes, under normal circumstances.
Modules are bound to Gwyddion more tightly than plug-ins, so a substantial change in it may break compatibility. Normally, all new versions are both source and binary level compatible with previous ones and modules linked against old versions work even with the newest one.
Gwyddion 2.0 is neither binary compatible (so modules have to be recompiled) not source compatible (so beside recompilation, some changes in module code are necessary) with 1.x versions. But all 2.x version will be backward compatible with other 2.x versions again.
Actually, there already was a one unplanned incompatible change, in version 1.3, where a serious bug present in previous versions could not be fixed while retaining compatibility. This should not happen again.
When the amount of changes will warrant a new release.
Assuming a reasonable development pace this policy means a new version is released once a month or two on average. Sometimes the development is slower so it takes longer.
As many other projects have realized, waiting until features are finished leads to excessive delays. Hence features that are not ready yet are simply omitted from the release. Do not take it personally if you have a personal interest in something left out – since we do not wait another release, meaning another chance, will occur soon.
If you are a Freshmeat.net user, you can subscribe to project Gwyddion (there's a Subscribe to new releases link near the bottom, you have to log-in to subsrcibe).
If you are a SourceForge.net user, you can subscribe to project Gwyddion (see the envelope icon in Latest file releases section, you have to log-in to subsrcibe).
SourceForge also offers a RSS feed, although this method is probably a bit silly.
OS-wise, Gwyddion is known to work on GNU/Linux, Microsoft Windows, Mac OS X, and FreeBSD. Architecture-wise, it has been tested on i386, AMD64, and PowerPC. It should work on any Unix-like system where Gtk+ and other dependencies work.
Most probably you are looking at the PSDF method of fractal dimension estimation. It uses a log-log plot with arbitrary shifts and scale. Use the statistical functions tool to obtain PSDF in absolute units.
The x axis units are then lateral_unit-1 and y axis units lateral_unit × value_unit2. The normalization corresponds to the PSDF expressions for various surfaces that can be used to fit rms and autocorrelation length of rough surfaces in graph fitting.
Many different PSDF normalizations can be found in the literature, together with reasons why they are better than others. PSDF in Gwyddion is based on the concept of an infinite (rough) surface. The measured data is a finite-resolution measurement on a finite area which is assumed to have the same statistical properties as the entire surface.
The total energy of an infinite surface is infinite so, a meaningful quantity is the energy per unit interval. The PSDF displayed in Gwyddion can be then imagined as this function. It is sampled in certain points given by the discrete nature of the calculation, nevertheless, the values should be approximations of W1(k) that results from contignuous FT of the entire infinite surface.
This has the following nice consequences:
Also, for contignuous distributions, the square of a density of some quantity is not the density of the same quantity squared. Hence normalizations of PSDF and Fourier coefficients generally need to be considered separately.
Unfortunately, we do not have any public FTP upload space.
The preferred method of sending large files is to upload them to a file hosting service/file deposit and send the link.
Not preferred, but also possible is to send files by e-mail. In such case compress the files with 7zip, bzip2 or zip because:
Please do not send large files to the mailing lists, they will be rejected.
--as-needed and it broke. How to fix it?Contrary to the popular belief linking with --as-needed would
make Gwyddion slow and bloated, not more efficient. So the short answer is:
you fix it by not linking with --as-needed.
On platforms that support it, and that means at least all modern Unix
systems, the main application is linked with some “redundant” libraries
and modules are not linked with anything (unless they need a specific extra
library). Symbols in modules are resolved from the libraries the main
application was linked with. Obviously, --as-needed makes this
optimization impossible and every module then has to be linked with all
libraries it requires – this is less than the full set of libraries
but still much more than none. It takes more time to build (even 2×)
and install (almost 10×) and it makes the program start more slowly (module
loading time increases 2×).
But if you insist then pass --enable-library-bloat option
to configure and all the bloat will be linked in.