Activity for ciroki
-
ciroki committed [r784] on Code
DAE Tools c++ SDK small update
-
DAE Tools 2.5.0 released
-
OpenCS 2.5.0 released
-
Documentation update.
-
C++ SDK update
-
python 3.13 updates
-
pyqt6 updates
-
Porting PyQt5 to PyQt6
-
Windoes changes
-
-
- OpenCS:
-
- OpenCL:
-
Version 2.3.0
-
OpenCS:
-
OpenCS:
-
Updated manuscript length and DOIs.
-
Initial submission
-
OpenCS 2.2.0 released
-
DAE Tools 2.2.0 released
-
DAE Tools 2.2.0 and OpenCS 2.2.0
-
Windows compilation updates.
-
OpenCS:
-
OpenCS 2.1.0 released
-
OpenCS:
-
DAE Tools 2.1.0
-
OpenCS 2.0.0 released
-
OpenCS
-
OpenCS and daetools:
-
Updated third party libraries in daetools and OpenCS:
-
Updated third party libraries in daetools and OpenCS:
-
Fixed compilation on RHEL 9.
-
Replaced boost::filesystem with std::filesystem.
-
DAE Tools:
-
deal.II namespaces update.
-
OpenCS 1.2.0 released
-
DAE Tools 2.0.0 released
-
That's a problem in daetools. libgfortran.so.3 is set only for core modules not for solver libraries; hence, CMake picks up the default fortran version. I'll fix that in the next release. Dragan
-
Yes, thanks. Hoewver, I do not see the values of variables, residuals and sensitivity residuals printed. Could you set these options not in the run function but before a call to it, i.e. if __name__ == "__main__": cfg = daeGetConfig() cfg.SetBoolean("daetools.core.printInfo", True) cfg.SetBoolean("daetools.IDAS.printInfo", True) ... run() because some options are collected from the options file at the very beginning. Dragan
-
Hi Manuel, You are right, there are problems with the optimisation part. In addition to a number of people already reported it, I am aware of that too. The optimisation support has not seen an update for many years so a major revision is required. This is true in particuar for IPOPT which has a new interface. I'll have a look and let you know what can be done. Dragan
-
Hi Manuel, I noticed that too. I am not sure why it happens, but it is daetools related (not python or os). I'll check what is going on and let you know. What you can do is set printInfo to true in daetools.cfg (or programmatically using daeGetConfig function) for both daetols.core and daetools.IDAS and see if there are some strange numbers, infinity or not a number values. Dragan
-
Hi Manuel, Good that it works now. On the other hand, there might be a problem with fortran in linux. Good that you brought it to attention. The problem with the optimisation is that it uses a library with the compiled fortran code using a different fortran than what is specified in dae.pri config file. That needs to be resolved in the future version. Please first try to install version 3. Usually it is available in most distributions. Then it would be good to compile it from source. In the latter...
-
Hi, True, there could be problems on new versions. DAE Tools is compiled against libgfortran 3 which is the only version available on old systems. On new versions typically there is an option to install libgfortran.so.3 along side with 5. It seems this is not the case for Fedora. Perhaps try creating a symlink named libgfortran.so.3 that points to libgfortran.so.5? Dragan
-
Hi Chanbum, No problem. The compilation requires some headers which are located in OpenCS/build/include directory so compilation of OpenCS is required. Just do the following: sh compile_libraries.sh opencs after sh compile_libraries.sh all. This should actually be included in the all option. Thank you for discovering it. I'll add it to the documenation too. Cheers Dragan
-
Hi, No problem, you're welcome. Just use svn checkout -r 755 svn://svn.code.sf.net/p/daetools/code daetools" to get revision 755. This is the version 1.9.0. Or, you can download the zip archive from http://www.daetools.com/downloads.html. Cheers Dragan
-
Hi Chanbum, There are many changes since 1.9.0, incompatible and unfinished. Just checkout revision 755 and it should be fine. Cheers Dragan
-
Hi Manuel, Thanks for trying. No, if it does not work than that's it unilI fix it (in 1.9.1). It probably does work in python 2.7. Dragan
-
Hey Manuel, The status is the following: I reproduced the error on my computer, found where the problem (the most likely) is, but the the exact reason is still not clear to me. Therefore, I did try some things in the latest release, but in general the problem is still there for some versions of MacOS. Please try the new version, see if it works and let me know. The next version will probably have this resolved. Cheers Dragan
-
deal.II namespaces update.
-
DAE Tools:
-
Compile and install daetools core modules and solvers as shared libraries on Windows
-
OpenCS:
-
Hi, Can you do one more thing: run python and send me the compiler info. I.e. you can get something like: $python Python 3.6.2 |Continuum Analytics, Inc.| (default, Jul 20 2017, 13:51:32) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> Perhaps there is some collision between python and my extension wrappers. Dragan
-
Hi Manuel, You actually do not need the compiler, just the runtime libraries. I checked and the only libraries linked are libSystem and those from gcc-8. So everything should be fine. I'll try to install some recent macOS to try to reproduce the error. Dragan
-
Hi Manuel, In the new version DAE Tools is compiled using Homebrew gcc 8. It should be a default version so you can just update homebrew. Otherwise install gcc@8. This needs to be checked: it may or may not require linking gcc using: brew link gcc Can you check if it works? Dragan
-
OpenCS 1.1.0 released
-
DAE Tools 1.9.0 released
-
Hi, Reporting times include points in time where the results should be reported next (after initialisation at t=0). Just don't include 0 and it should be ok. Dragan
-
DAE Tools 1.9.0
-
Windows compilation fixes.
-
pyOpenCS python wrapper
-
-
DAE Tools:
-
The major revision of OpenCS:
-
Hi Jaime, It runs on the local machine (localhost). If it can't connect then it is a problem with i.e. windows firewall. Can you check that? Otherwise, just use the following class: class daePickleDataReporter(daeDataReporterFile): # Saves data as the Python pickle which can be opened in DAE Plotter. def __init__(self): daeDataReporterFile.__init__(self) def WriteDataToFile(self): try: from daetools.dae_plotter.data_receiver_io import pickleProcess pickleProcess(self.Process, self.ConnectString)...
-
Hi, I am not completely sure how to do it in particular for Hysis, but in general all thermo-physical property managers are registered as a COM component and have a list of package names, typically created using the vendor's GUI. There should be something in the Aspen documentation and also online. From what I could see there is the Fluid Package Manager and there you create and configure the new FluidPackag -: which property package (should be CAPE-OPEN 1.1 I guess), components etc. I am not sure...
-
Hi again, Can you try to start DAE Plotter manually before you run the simulation and see what happens? Then you should be able to run multiple simulations. If the DAE Ploter GUI starts it is fine, otherwise could be a firewall issue. Cheers Dragan
-
Hi, No problem. This error means that you cannot continue after connecting to the data reporter you selected. The connection is broken for some reasons (or even not connected at all). The connection can be broken if you use the default data reporter which starts the DAE Plotter (TCP/IP based). For other types of data reporters the problem can be with the path to the file you specified (i.e. insufficient permissions). Please let me know which data reporter you use so I can be more specific. Cheer...
-
DAE Tools 1.8.1 released
-
OpenCS 1.0.0 released
-
OpenCS 1.0.0 released
-
- Implemented Open Compute Stack (OpenCS) framework:
-
No problem. Great that it works. Can't say for sure, but these scripts use the default python. It could be that the default python command in your system is python2 and you explicitly used python3. Try with: python -m daetools.dae_plotter.plotter and python3 -m daetools.dae_plotter.plotter and see what happens. It should work in the second case. Probably it is the same issues with daeexamples.
-
I tested in Ubuntu 16.04 and this is the working solution. The lines starting at 291: docs_html_dirs = [] for f in os.walk(docs_html_folder): try: p = os.path.relpath(f[0], daetools_folder) docs_html_dirs.append(os.path.join(p, '*.*')) except: pass should be replaced wth: docs_html_dirs = [] for root, dirs, files in os.walk(docs_html_folder): try: for f in files: full_path = os.path.join(root, f) relative_path = os.path.relpath(full_path, daetools_folder) docs_html_dirs.append(relative_path) except:...
-
Since I do not get that error, can you test the solution for me? Please replace the lines in setup.py: docs_html_dirs = [] for f in os.walk(docs_html_folder): try: p = os.path.relpath(f[0], daetools_folder) docs_html_dirs.append(os.path.join(p, '*.*')) except: pass with docs_html_dirs = [] for root, dirs, files in os.walk(docs_html_folder): try: if files: relative_path = os.path.relpath(root, daetools_folder) docs_html_dirs.append(os.path.join(relative_path, '*.*')) except: pass and let me know if...
-
Error during installation attempt at Ubuntu 16.04
-
I would need one more thing. Can you guys take setup.py, uncomment line 291: print('\n'.join(docshtmldirs)) add sys.exit() after it and send me the output? I'd like to check the contents of the list on buntu 16.04.
-
I just saw the post, it was stuck in moderation. From the output I would say it tries to copy a folder as a file and fails. If I can recall correctly I faced something similar in the past, but can't remember the versions of python and the OS. I'll try to install Ubuntu 16.04 and detect the error. Dragan
-
Well, it is hard to tell why it fails to copy the files from a folder when the files do exist. Could you send me the output and perhaps run it with the --verbose flag? Perhaps it can help with the source of the error.
-
It is difficult to tell what is the error. Does the daetools/docs/html/_static/bootstrap-3.3.6 folder exist? What is your Python version? The warning is probably due to the outdated setuptools. You are correct about python-pyqt5, I'll update the docs.
-
Great. Thanks. In general I can generate xhtml files. The main reason for xml files was model serialization: one can load the saved .xml file and regenerate the model (although not fully functional at the moment). An additional benefit is having model reports. If that is not required, the new SaveModelReportHtml function can be used (internally using lxml, but I need to check if lxml can use MathJax to create html or just leave as it is and process equations in a browser). I can copy MathJax to daetools.com...
-
Hi Jaime, Yes, you're correct. First, the model hierarchy needs to be traversed and all unique model types collected. For instance, if the model M1 contains sub-models SM1 and SM2 and SM2 contains SSM1 sub-model, the generated file names could be: M1.xml M1.SM1.xml M1.SM2.xml M1.SM1.SSM1.xml The version control can be added. I believe what you meant is that .xsl and .css file names include the version, i.e.: dae-tools-1.0.xsl and dae-tools-1.0.css and the .xml reports link the appropriate version....
-
Hi Jaime, Yes, it does show all components (sub-models). However, the idea behind my approach is the following. Models can have many sub-models. What if a model has an array of 100 instances of the same model? Should all of them be displayed? In the approach I chose, only the structure of the top-level model is displayed and only the sub-model types and names shown. The structure of the sub-model can be saved into a separate xml file. This method is better, in my opinion. What is missing now are...
-
Hi Jaime, It seems it does not work only if you explicitly tranform the .xml into the .html format (i.e. using lxml). The block from the .xsl file below: <script type="text/x-mathjax-config"> MathJax.Hub.Config({ jax: ["input/TeX", "output/HTML-CSS"], tex2jax: { inlineMath: [ ['$','$'] ] }, displayAlign: "left", CommonHTML: { linebreaks: { automatic: false}, preferredFont: null, mtextFontInherit: true, styles: { '.MathJax_Display': { "margin": 0 } } }, "HTML-CSS": { linebreaks: { automatic: false},...
-
Hi Jaime, Good, thanks a lot for checking it. I should add it to the documentation to make clear what needs to be done when running on macOS. Cheers Dragan
-
Hi Jaime, It is possible to use the DAE Plotter GUI, just there are problems with starting it automatically in macOS when one attempts to connect the tcp/ip data reporter. Previously, one had to manually start the DAE Plotter GUI. Now, it will try to start it before connecting. This part does not work in macOS at the moment. There you have to start it using i.e.: python -m daetools.dae_plotter.plotter Please try and let me know if it works. Cheers Dragan
-
- daeIDASolver.SetLASolver now accepts the solver type and the preconditioner
-
Yes, the extension modules are from 1.7.3, indeed. I will upload the new version now.
-
Judging by the dates, the files appear to be from 1.7.3. I'll double check, perhaps I copied old extension modules.
-
Well, could be, I will check.
-
Well, strange. Do other flags work, i.e. those for distributed equations boundaries: eOpenOpen etc.? I checked, they are all defined in the same module (pyCore).
-
eEvaluationTree_OpenMP is defined in pyCore. Thus, the line below: simulation.EvaluationMode = eEvaluationTree_OpenMP should work provided that the pyCore module has been successfully imported. Can you check if it is imported? Dragan
-
My bad, please try this: propertyPath = 'daetools.core.equations.evaluationMode' eMode = 'evaluationTree_OpenMP' cfg.SetString(propertyPath, eMode) It could be a problem with the way the functions in the extension module are defined. Dragan
-
Hi Jaime, Issue 1. I checked on my machine and both ways work. When you use: simulation.EvaluationMode = eEvaluationTree_OpenMP what error you get? Also, please try this and let me know if it works: eMode = 'evaluationTree_OpenMP' cfg.SetString('daetools.core.equations.evaluationMode', eMode) Issue 2. You are right: OpenCL implementation of the Compute Stack Evaluator is not available for macOS. if I can recall correctly, I had some problems with the OpenCL runtime installation so it couldn't be...
-
Hi Jaime, Well, good that you found a solution and it works. On the other hand, it is strange that it is not handled by the python venv. I know that macOS prohibits tampering with the dynamic library paths for security reasons. That's why I do not rely on LD_LIBRARY_PATH and friends but use the @loader_path so that the libraries are always found relative to the extension module being loaded. The only exceptions are libSystem that is always fixed and libpython that is looked for in the runtime. It...
-
Hi Jaime, Well, what happens in your case It is very interesting. I recalled what is being done during the daetools compilation and remembered the reasons for @rpath: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html#//apple_ref/doc/uid/TP40008306-SW1 If libpython3.6m.dylib is in the search path then it should work fine since it is already loaded by the python executable. Can you run otool -L pyCore.so...
-
Hi Jaime, Something is not standard in your installation. The path to libpython you sent me in the first email is not in the sys.path and you have '/Library/Frameworks/Python.framework/Versions/3.6/lib/python36.zip' in it. I did not use virtual environments often, but I did some quick look. Often there are problems, it seems. Python binary is copied but I am not sure if it copies libpython as well. By the way, it is a simple question but, did you activate the environment? Can that be a problem? I'll...
-
- Added daetools_mpi_simulator as a generic simulation software for parallel integration
1 >