ASCEND bug tracker - Issues

0000595: Plans to Upgrade to PyGObject and Python3?

Wed, 11 Dec 2019 22:46:27 +1100

I recently released version 1.0.0 of Gaphas, which upgraded PyGTK to PyGObject. I want to make sure that you know about this change so that you can pin version 0.7.2 of Gaphas and I also want to see if you have any plans to upgrade ASCEND as well?

The countdown is on for support ending for legacy Python (https://pythonclock.org/), and PyGTK is also no longer maintained. I also have quite a bit of experience upgrading to PyGObject, GTK+3, and Python 3, so I could provide some guidance if desired.

0000530: Console (IPython) pane doesn't show with recent IPython versions

Sun, 27 May 2018 17:37:35 +1000

There is an error saying that 'module' has no attribute 'iplib'.

This looks like IPython's API might have changed. We could check the Accerciser project from which our GTK+IPython code came, and see if there is an update.

Occurs with Windows 7 and also Ubuntu 12.04.

0000594: Reference state FPROPS_REF_TPHS0 doesn't work correctly in oxygen.c

Mon, 15 Jan 2018 23:10:38 +1100

Test cases are consistently wrong for oxygen owing to what looks like an error in the implementation of the reference state FPROPS_REF_TPHS0 (refstate.c).

0000590: [Compile error with GCC-6.0] ascend/compiler/anoncopy.c

Tue, 07 Nov 2017 20:34:04 +1100

Hi all,

ascend (svn 3100) cannot be built with GCC-6 on Fedora 24+ :

ascend/compiler/anoncopy.c:167:31: error: expected unqualified-id before 'new'
register struct ArrayChild *new,*src;
^~~
ascend/compiler/anoncopy.c:167:31: error: expected initializer before 'new'
ascend/compiler/anoncopy.c:173:2: error: 'src' was not declared in this scope
src = (struct ArrayChild *)gl_fetch(list,c);
^~~
ascend/compiler/anoncopy.c:174:6: error: expected type-specifier before '=' token
new = MALLOCPOOLAC;
^
ascend/compiler/anoncopy.c:175:7: error: expected type-specifier before '=' token
*new = *src;
^
ascend/compiler/anoncopy.c:177:16: error: expected type-specifier before '->' token
if (new->inst !=NULL) {
^~
ascend/compiler/anoncopy.c:177:16: error: expected ')' before '->' token
In file included from ascend/compiler/anoncopy.c:74:0:
ascend/compiler/anoncopy.c:178:35: error: expected type-specifier before '->' token
switch (InstanceKind(new->inst)) {

Full log: http://fpaste.org/335182/

0000592: 'Curve default constructor' and GCC6

Sun, 03 Sep 2017 21:53:06 +1000

Issue discussed and resolved in the Fedora devel mailing list:

In C++98 constructing std::vector v(1); would invoke X's default constructor in the caller's context, so if the default constructor is private then the caller must be a member or friend of X. In C++11 the default constructor will be invoked deep inside std::vector, or one of its helper functions. The code is basically invalid in C++11. It should either make the default constructor public (the simplest fix), or change how the vector is constructed (which seems to come from Swig, so might be difficult).

> gcc -o tcltk/interface/AscBitmaps.os -c -fvisibility=hidden ""-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -Wl,-z,relro -pie -Wl,-z,now"" -fPIC -DHAVE_GCCVISIBILITY -I. -I/usr/include/tcl8.6 -I/usr/include/tcl8.6 tcltk/interface/AscBitmaps.c
In file included from /usr/include/c++/6.0.0/vector:62:0,
from ascxx/ascpy_wrap.cc:3038:
/usr/include/c++/6.0.0/bits/stl_construct.h: In instantiation of 'void std::_Construct(_T1*, _Args&& ...) [with _T1 = Curve; _Args = {}]':
/usr/include/c++/6.0.0/bits/stl_uninitialized.h:519:18: required from 'static _ForwardIterator std::__uninitialized_default_n_1<_TrivialValueType>::__uninit_default_n(_ForwardIterator, _Size) [with _ForwardIterator = Curve*; _Size = unsigned int; bool _TrivialValueType = false]'
/usr/include/c++/6.0.0/bits/stl_uninitialized.h:575:20: required from '_ForwardIterator std::__uninitialized_default_n(_ForwardIterator, _Size) [with _ForwardIterator = Curve*; _Size = unsigned int]'
/usr/include/c++/6.0.0/bits/stl_uninitialized.h:637:44: required from '_ForwardIterator std::__uninitialized_default_n_a(_ForwardIterator, _Size, std::allocator<_Tp>&) [with _ForwardIterator = Curve*; _Size = unsigned int; _Tp = Curve]'
/usr/include/c++/6.0.0/bits/stl_vector.h:1309:36: required from 'void std::vector<_Tp, _Alloc>::_M_default_initialize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = Curve; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::size_type = unsigned int]'
/usr/include/c++/6.0.0/bits/stl_vector.h:281:30: required from 'std::vector<_Tp, _Alloc>::vector(std::vector<_Tp, _Alloc>::size_type, const allocator_type&) [with _Tp = Curve; _Alloc = std::allocator; std::vector<_Tp, _Alloc>::size_type = unsigned int; std::vector<_Tp, _Alloc>::allocator_type = std::allocator]'
ascxx/ascpy_wrap.cc:27027:69: required from here
/usr/include/c++/6.0.0/bits/stl_construct.h:75:7: error: 'Curve::Curve()' is private within this context
{ ::new(static_cast(__p)) _T1(std::forward<_Args>(__args)...); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ascxx/plot.h:10:0,
from ascxx/ascpy_wrap.cc:4058:
ascxx/curve.h:15:2: note: declared private here
Curve();
^~~~~
solvers/qrslv/qrslv.c: In function 'qrslv_get_default_parameters':
solvers/qrslv/qrslv.c:2806:9: warning: variable 'make_macros' set but not used [-Wunused-but-set-variable]
int32 make_macros = 0;
^~~~~~~~~~~
solvers/qrslv/qrslv.c:2804:18: warning: variable 'lo' set but not used [-Wunused-but-set-variable]
union parm_arg lo,hi,val;
^~
solvers/qrslv/qrslv.c:2803:18: warning: variable 'sys' set but not used [-Wunused-but-set-variable]
qrslv_system_t sys = NULL;
^~~

0000456: METHOD error handling needs work

Sun, 23 Apr 2017 18:22:14 +1000

When METHODS are run from the PyGTK GUI, the error_reporter_tree thing is used to determine if any errors were experienced, rather than the Proc_enum output of the Initialize function (ascend/compiler/initialize.c).

The reasons for this had something to do with difficulty in communicating errors from various kinds of External Methods, I think such as [[ExtPy]]. This problem needs to be cleared up so that we can use our C-layer API more cleanly from the Python GUI.

0000371: problem with error_reporter_tree_end if no output is made during it

Sun, 23 Apr 2017 18:19:39 +1000

I think there was a problem with this previous, and that is the reason for all the superfluous debug output, eg

base/generic/utilities/error.c:161 (error_reporter_tree_end): TREE END
base/generic/utilities/error.c:308 (va_error_reporter): DONE WRITING TREE

Need to work out if problem still there, and then remove debug output if poss.

0000582: cpow missing in MinGW32

Fri, 07 Apr 2017 13:44:07 +1000

In MinGW32 (official MinGW) the 'cpow' function in complex.h is missing from libm. This means that our fprops function for solving PR EOS doesn't work without a bit of a hack.

We should make sure that when CPOW is available, the native function is used, and disable the current hack in models/johnpye/fprops/cubicroots.c.

0000591: FIx for Unknown SWIG preprocessor directive error.

Fri, 10 Feb 2017 17:50:38 +1100

The below commit fixes the Unknown SWIG preprocessor directive error, when using Swig 3.0.8 on Ubuntu 16.04.

This is due to a change in the syntax how comments in Python blocks are treated.

The fix works with Swig 2.x (Swig 2.0.11 on Ubuntu 14.04)

https://github.com/georgyberdyshev/ascend/commit/6962ef6c2ca36ff6cfff85e98c2daeac82619b82

Please merge the changes from the above URL or the attached patch.

Thanks in advance, Georgy

0000393: pygtk install ignores INSTALL_PREFIX

Thu, 09 Feb 2017 16:32:57 +1100

Snippet below.
If I wanted a root install, i would be root. in all other cases,
the python wrappings install convention should be put it in $prefix/lib*/*
as usual with python. Issue a reminder and sed the correct pythonpath settings
into an scripts that need them. As it is, I cannot test pygtk interface.

0000584: integrator behaves strangely when units of 't' variable are not seconds

Wed, 17 Aug 2016 03:37:00 +1000

If the user interface is configured so that the units of the independent variable are not equal to base SI units (eg days 'd' instead of seconds 's'), then bad things seem to happen with the Integrator dialog. Setting up the integration limits and time-steps seems to be going wrong somehow. Perhaps the unit conversion is being multiplied instead of divided?

Most relevant file is branches/ksenija2/pygtk/observer.py.

The issue also seems to impact the plotting of 'events' in a simulation, etc in the branches/ksenija2/models/ksenija/thermostat.a4c model.

0000593: var.setFixed(1) in model causes error; var.setFixed(True) no error

Fri, 22 Jul 2016 14:47:34 +1000

Maggie has a model (/home/maggie/ascend/models/varflux/Sinusoid/moltensalt-plot-sinusoid.py) that causes errors when her extpy script uses var.setFixed(1) and the errors go away when changed 'True' instead of '1'. Suspect a problem with the SWIG wrapper of 'instance.h'.

0000589: thermal conductivity code incomplete (thcond)

Thu, 31 Mar 2016 17:37:16 +1100

Thermal conductivity code has been partially implemented eg for nitrogen, but is not yet functioning correctly. Debugging and fixing required.

0000586: string overflows buffer in WriteLogRelToString

Fri, 18 Mar 2016 19:07:10 +1100

Hello there,

In function 'sprintf',
inlined from 'WriteLogRelToString' at ascend/compiler/logrel_io.c:773:5:
/usr/include/bits/stdio2.h:33:10: warning: call to __builtin___sprintf_chk will always overflow destination buffer

Source code is

result = ASC_NEW_ARRAY(char,15);
if (result == NULL) return result;
sprintf(result,"NULL logical relation\n");

23 into 15 won't go. Suggest code rework.

Regards

David Binderman

0000588: Reference state TPHS0 seems to have an error

Mon, 07 Mar 2016 10:25:14 +1100

The reference data for enthalpy for oxygen (oxygen.c) is not working correctly compared to the 'OT0' reference state used in FPROPS. Not clear why this is, some testing of ideal property data perhaps needed.

0000587: Too less units after selecting preffered

Tue, 18 Aug 2015 00:32:10 +1000

If you choose kg/kmol or g/g_mole preffered units of molar_weight_constant, kg/mol dissappears. The problem is libascend returns one less unit (function library.getUnits()). It returns 450 instead 451 when no preffered units are selected.

0000585: Compile against Sundials-2.6.1

Tue, 07 Apr 2015 03:23:23 +1000

Sundials-2.6.1 does not provide sundials-config anymore.
This lack imposes changes of Ascend code to detect properly all Sundials libraries which IDA solver needs.

I'm trying to patch scons/sundials.py file and change Sundials libraries detection (please, see patch attached). However scons-check does not find the right Sundials version, IDA solver is disabled.

Please, I need help to discover how to fix this problem.

0000564: crash in 'SetRealAtomValue' on ubuntu 12.04 64-bit

Sun, 29 Mar 2015 01:49:44 +1100

On Ubuntu 12.04 64-bit, I get a crash when I try to run the solver on the models/johnpye/combinedcycle_fprops.a4c model in trunk.

Running 'pygtk/ascdev' as detailed in [[Building ASCEND]], I then just load the model and click solve; then I get a crash.

0000577: Can't stop integration

Mon, 28 Jul 2014 18:42:54 +1000

The 'stop integration' button doesn't work.

0000583: Patches for issues with python, tcl/tk and scons build script

Sat, 07 Jun 2014 04:25:10 +1000

Hi,

While trying to build ascend on openSUSE I had to cope with some small issues:

- pygtk module could not be build because of a deprecated property;
- tcl/tk could not be build also because of deprecated access method;
- sundials validity check failed;
- ufsparse on many distributions now goes to "/usr/include/suitesparse";
- SConstruct had many checks that should be changed.

I patched everything I found and it is building properly (almost) now. There is a last issue, though, I could not spot the correct place to change: where goes the "models" modules. With the changes I did, I expected them to be installed on "/usr/lib64/ascend/models" and, even though this is the place where the installer put them, to make ascend actually find them I had to create a link from there to "/usr/share/ascend/models", after what, everything seems to be working fine.

Attached are the patches I had to apply.

Let me know if I may help with something else.

Best regards,
André

0000581: windows: installed versions 64-bit and 32-bit don't coexist

Thu, 05 Dec 2013 19:23:02 +1100

If the 32-bit version of ASCEND is installed after the 64-bit version has been installed on the same machine, the 32-bit version of ASCEND seems to work incorrectly and crash.

A possible cause of this is that both .ascend.ini and environment variable ASCENDLIBRARY etc are not sensitive to whether 64-bit or 32-bit ASCEND is running. This means that in some cases, attempts to load 64-bit DLLs from 32-bit ASCEND could be occurring.

The solution would appear to be get away from using environment variables for ASCEND, and not to store any (absolute) file paths in .ascend.ini. (Or to have different versions of .ascend.ini depending on which 32/64 version is running).

Alternatively, we just force only one ASCEND to be installed at a time!

0000579: Installation and runtime are not compatible with the use of the PyGTK all-in-one package.

Fri, 25 Oct 2013 13:09:37 +1100

The configuration of the GTKLIB variable in ascend does not support the use of the all-in-one PyGTK installer. The all-in-one installer includes GTK, PyGTK, PyCario and PyGObject and manages the configuration of the python path to ensure that everything is configured correctly. From a very brief review, it appears to me that the ascend launch script looks to configure the GTK library paths on its own and this causes a problem.

This behavior is only observed after the installer is 'tricked' into working by installing GTK manually and adding it to the system path. Of course, this indicates that the installer is also incompatible with the use of the all-in-one PyGTK installer.

0000578: python dependency on gtksourceview2 makes problems with Windows builds

Sat, 17 Aug 2013 21:33:35 +1000

pygtk/moduleview.py
and optionally also pygtk/canvas/blockproperties.py and pygtk/canvasproperties.py

These files now explicitly import gtksourceview, but this Python module is not available in our recommended GTK+ distribution as hosted on the ASCEND file downloads section in SF.net.

We need to make the pygtk/moduleview.py code only optionally depend on gtksourceview, it should failover to a gtktextview in those cases, for the moment.

0000574: ascend could not be started.

Tue, 06 Aug 2013 09:10:07 +1000

I build the following PKGBUILD to install ascend.

#********

pkgname=ascend
_pkgver=0.9.8
pkgver=$_pkgver.$(date +%m%d)
pkgrel=1
pkgdesc="ASCEND is a system for solving systems of equations"
arch=(i686 x86_64)
url="http://ascend4.org"
license=('GPL')
depends=('flex' 'bison' 'python2' 'scons' 'swig'
'boost' 'tcl' 'tk' 'graphviz' 'blas' 'gtk' 'pygtk'
'tktable'
'python2-matplotlib' 'python2-numpy' 'ipython' )
makedepends=('cmake' 'make' 'gcc')
options=(!emptydirs)
_git=yes

getsource() {
cd "$srcdir"
msg "Connecting to svn server...."
if [ -d "$1"]; then
cd "$1" && svn co svn://ascend4.org/code/trunk ascend
else
svn co svn://ascend4.org/code/trunk ascend
fi

msg "svn done or server timeout"
}

prepare() {
cd "$srcdir"
getsource
}

build() {
cd "$srcdir"/ascend
sudo scons install
}

package() {
export PATH=$PATH:/bin
}

#*******

obviously, sundials and tkatables had to be installed as well. tktables let it to be installed from aur. for sundials, the pkgbuild in aur is very old, so i rewrote this :

pkgname=sundials25
_pkgname=sundials
pkgver=2.5.0
pkgrel=1
pkgdesc="Suite of nonlinear differential/algebraic equation solvers"
arch=('i686' 'x86_64')
url="https://computation.llnl.gov/casc/sundials/main.html"
license=('BSD')
provides=('sundials')
conflicts=('sundials')
options=('!libtool' '!emptydirs')

build() {
wget http://computation.llnl.gov/casc/sundials/download/code/${_pkgname}-${pkgver}.tar.gz
cd ${srcdir}
tar -xzf ${srcdir}/${_pkgname}-${pkgver}.tar.gz
cd "$_pkgname-$pkgver"

./configure F77=gfortran --prefix=/usr --disable-mpi --with-cflags=-fPIC --enable-shared
make || return 1
sudo make prefix="/usr" install
}

installation was fine.
afterwards, when i do this: ascend testlog10.a4c
i get this:

# prints a lot of env vars ..
sys.path[0] = /usr/local/bin
Adding ASCEND_PYTHON=/usr/lib/python2.7/site-packages/ascend to python path
Traceback (most recent call last):
File "/usr/local/bin/ascend", line 215, in
import ascpy
File "/usr/lib/python2.7/site-packages/ascend/ascpy.py", line 2181
print "XLabel:",self.getXLabel()

0000575: diagnose window shows units but doesn't make conversion

Tue, 16 Jul 2013 17:50:30 +1000

diagnose window shows units but doesn't make conversion