Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Stefano Zaghi
    @szaghi
    hi victor, here we should work together more comfortably
    victorsndvg
    @victorsndvg
    Ok, I'm going to enable notification to follow the channel
    Stefano Zaghi
    @szaghi
    I see the new dirs structure. nice
    will allow more testes
    victorsndvg
    @victorsndvg
    I's the same structure I use in other project to allow recursive .f90 sources and do not have to include it manually in the CMakeLists.txt. I' will comment the HUGE option
    Stefano Zaghi
    @szaghi
    :+1:
    Stefano Zaghi
    @szaghi
    Victor, why in the VTK_INI_XML_READ you are forcing 'ascii' format? there are problems with binary/raw files?
    sorry, I was reading PVTK not vtk_ini
    sorry
    victorsndvg
    @victorsndvg
    Oh, It's a good point that I forget to tell you. I think that is not necesary to store the type of data, because we always read ascii. But in order to maintain the coherence I "forced" the format in the VTK derived type. It can be removed if you want
    Stefano Zaghi
    @szaghi
    no, i have another problem. I would like to create a unique interface for XML_INI and XML_INI_READ but due to their signature it is impossobile. I am thinking to adding some argument for distinguishing importer from exporter but it is not simple... all things coming out are orrible...
    victorsndvg
    @victorsndvg
    I was thinking how to merge athe reader/writer subroutines into a single one, but I'm not getting any brilliant idea... I still thinking in it
    Today I did a pull request of the PVD-importers into Lib_VTK_IO importers branch due to the big similarities between the two branches.
    victorsndvg
    @victorsndvg
    An important think about CMake compilation is that the target library is'n call Lib_VTK_IO, now is libvtk_io. What do you think about this name? In my opinion is more "UNIX like". I think is more natural to link with -lvtk_io than -l_vtk_io. I also prefer libvtkio (-lvtkio). What do you think? Your decision about it's an easy change into the CMakeList file. Of course it's only a suggestion, you can choose what you want!
    Stefano Zaghi
    @szaghi
    Hi victore, all is good. Your PR is under merging now :-) as the name is concerned, you have anticipated me for a fraction of second! I am watching the new great idea of Chris (FLATPack) and the first that I thinked is that our library must have a more unix-like name... great job!
    Stefano Zaghi
    @szaghi
    @victorsndvg Where I can see into the CMake file the output name of the compiled library? I would like to consistently change also into fobos and makefile
    Stefano Zaghi
    @szaghi
    @victorsndvg I see that the importer use convert='little/big-endian'. This is not standard in both 2003 and 2008. We must highliths that now the library is not standard compliant
    victorsndvg
    @victorsndvg
    Oh... it's a pity... do you know any workarround to avoid the use of convert?
    In the main CMakeLists I assign the name of the proyect to the name of the library
    Line 8 (name of the project): PROJECT(VTK_IO Fortran C)
    Line 14 (assign name to library): SET(LIB ${PROJECT_NAME})
    CMake adds automatically the prefix 'lib' when you build any target as a library
    Stefano Zaghi
    @szaghi
    ok, no at the moment I cannot figure out a workaround, but it is a minor issue, just remember it
    victorsndvg
    @victorsndvg
    Hello Stefano. During this days i was trying to compile with IBM XLF v14.1 and I found and fix some minor problems. Look at the last commit of my repo if you want to see the changes. Now it compiles with BM XLF v14.1 :)
    Stefano Zaghi
    @szaghi
    Great! Currently I have not access to xlf :worried: Later in tge morning I will look your patch. Great victor!
    Stefano Zaghi
    @szaghi
    Dear @/all the new 2.0.0 version is here. It is an OOP refactoring of the old one. Now I can more easily add @victorsndvg importers into the library :+1:
    victorsndvg
    @victorsndvg
    :+1: I need to test it! are writers fully implemented yet!?
    Stefano Zaghi
    @szaghi
    I think that writers should have the same features of the old version
    at least for vtk and vtm
    victorsndvg
    @victorsndvg
    nice! you are so fast! :smile: Now i'm really bussy, but please let me know if you need some help with readers! Congratulations!
    Stefano Zaghi
    @szaghi
    @victorsndvg do not worry. Currently my free time is focused on FOODIE, so there is no rush for VTKFortran. I think that readers will arrive at september, however I have planned to exploit FoXy: I will use your great readers facility to improve FoXy and use it into VTKFortran... I am not so crazy as it appears, but I think this is a more sane approach
    victorsndvg
    @victorsndvg
    jaja of course not! you're not crazy. I'm agree with you that using a proper XML reader instead of my amateur workaround is the way to go
    Stefano Zaghi
    @szaghi
    naaa, your workaround was not amateur, but simply based on the old, bad style of Lib_VTK_IO... now we can do more :smile:
    P.S. If you have time track the work of Francesco Salvadore on an abstract PDE solver... it seems very interesting!
    victorsndvg
    @victorsndvg
    Ok, I will take a look as soon as possible!