xmds-devel — Discussion of issues related to development versions.

Re: [xmds-devel] Use importlib.resources instead of pkg_resources

[Mattias J. <m.t...@gm...>]

Thanks Rafael!

Patches have been applied.

Cheers,
Mattias


On Sat, 12 Oct 2024 at 18:53, Rafael Laboissière <ra...@de...> wrote:

> Dear XMDS developers,
>
> Use of pkg_resources is deprecated in favor of importlib.resources, which
> was introduced in Python 3.9.
>
> Please, find attached to this message a patches that is being currently
> applied to the Debian package xmds2. In order to put together this
> patch, I followed the recipe in
> https://setuptools.pypa.io/en/latest/pkg_resources.html
>
> If you want to keep backward compatibility with Python < 3.9, you
> might use the importlib_resources package instead of importing
> importlib.resources.
>
> Best,
>
> Rafael Laboissière
> _______________________________________________
> xmds-devel mailing list
> xmd...@li...
> https://lists.sourceforge.net/lists/listinfo/xmds-devel
>

Re: [xmds-devel] Use importlib.resources instead of pkg_resources

[Mattias J. <m.t...@gm...>]

Thanks Rafael!

Patches have been applied.

Cheers,
Mattias


On Sat, 12 Oct 2024 at 18:53, Rafael Laboissière <ra...@de...> wrote:

> Dear XMDS developers,
>
> Use of pkg_resources is deprecated in favor of importlib.resources, which
> was introduced in Python 3.9.
>
> Please, find attached to this message a patches that is being currently
> applied to the Debian package xmds2. In order to put together this
> patch, I followed the recipe in
> https://setuptools.pypa.io/en/latest/pkg_resources.html
>
> If you want to keep backward compatibility with Python < 3.9, you
> might use the importlib_resources package instead of importing
> importlib.resources.
>
> Best,
>
> Rafael Laboissière
> _______________________________________________
> xmds-devel mailing list
> xmd...@li...
> https://lists.sourceforge.net/lists/listinfo/xmds-devel
>

[xmds-devel] Fix invalid escape sequences in strings

[Rafael L. <ra...@de...>]

Sorry, I messed up with the Subject of my previous message. The 
Subject of this message is the correct one.
Content-Language: en-us

* Rafael Laboissière <ra...@de...> [2024-10-12 11:38]:

> Dear XMDS developers,
>
> Installation of the xmds2 package in Debian with a recent version of 
> Python (3.12, in my case), trigger these warnings:
>
>    Setting up xmds2 (3.1.0+dfsg2-8) ...
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/Tools/kde4.py:71: SyntaxWarning: invalid escape sequence '\s'
>      setregexp = re.compile('([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)')
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/Tools/qt4.py:257: SyntaxWarning: invalid escape sequence '\*'
>      """
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/lru_cache.py:19: SyntaxWarning: invalid escape sequence '\d'
>      re_num = re.compile('[a-zA-Z_-]+(\d+)')
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/lru_cache.py:43: SyntaxWarning: invalid escape sequence '\d'
>      re_num = re.compile('[a-zA-Z_]+(\d+)')
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/misc.py:86: SyntaxWarning: invalid escape sequence '\w'
>      m4_re = re.compile('@(\w+)@', re.M)
>
> The patch attached to this message fixes the issue.
>
> Best,
>
> Rafael

> Description: Fix invalid escape sequences (in doctring and regex strings)
> Author: Rafael Laboissière <ra...@de...>
> Forwarded: no
> Last-Update: 2024-10-12
>
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/Tools/kde4.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/Tools/kde4.py 
> @@ -68,7 +68,7 @@ def configure(self): 
> 	fu = re.compile('#(.*)\n') 
> 	txt = fu.sub('', txt)
>
> -	setregexp = re.compile('([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)') 
> +	setregexp = re.compile(r'([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)') 
> 	found = setregexp.findall(txt)
>
> 	for (_, key, val) in found: 
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/Tools/qt4.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/Tools/qt4.py 
> @@ -262,11 +262,11 @@ def apply_qt4(self):
>
> 	The additional parameters are:
>
> -	:param lang: list of translation files (\*.ts) to process 
> +	:param lang: list of translation files (\\*.ts) to process 
> 	:type lang: list of :py:class:`waflib.Node.Node` or string without the .ts extension 
> -	:param update: whether to process the C++ files to update the \*.ts files (use **waf --translate**) 
> +	:param update: whether to process the C++ files to update the \\*.ts files (use **waf --translate**) 
> 	:type update: bool 
> -	:param langname: if given, transform the \*.ts files into a .qrc files to include in the binary file 
> +	:param langname: if given, transform the \\*.ts files into a .qrc files to include in the binary file 
> 	:type langname: :py:class:`waflib.Node.Node` or string without the .qrc extension 
> 	""" 
> 	if getattr(self, 'lang', None): 
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/extras/lru_cache.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/extras/lru_cache.py 
> @@ -16,7 +16,7 @@ Do export WAFCACHE=/tmp/foo_xyz where xy 
> If missing, the default cache size will be set to 10GB 
> """
>
> -re_num = re.compile('[a-zA-Z_-]+(\d+)') 
> +re_num = re.compile(r'[a-zA-Z_-]+(\d+)')
>
> CACHESIZE = 10*1024*1024*1024 # in bytes 
> CLEANRATIO = 0.8 
> @@ -40,7 +40,7 @@ def sweep(self): 
> 	CACHEDIR = Options.cache_global
>
> 	# get the cache max size from the WAFCACHE filename 
> -	re_num = re.compile('[a-zA-Z_]+(\d+)') 
> +	re_num = re.compile(r'[a-zA-Z_]+(\d+)') 
> 	val = re_num.sub('\\1', os.path.basename(Options.cache_global)) 
> 	try: 
> 		CACHESIZE = int(val) 
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/extras/misc.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/extras/misc.py 
> @@ -83,7 +83,7 @@ def apply_copy(self): 
> def subst_func(tsk): 
> 	"Substitutes variables in a .in file"
>
> -	m4_re = re.compile('@(\w+)@', re.M) 
> +	m4_re = re.compile(r'@(\w+)@', re.M)
>
> 	code = tsk.inputs[0].read() #Utils.readf(infile)
>


> _______________________________________________ 
> xmds-devel mailing list 
> xmd...@li... 
> https://lists.sourceforge.net/lists/listinfo/xmds-devel

[xmds-devel] Fix invalid escape sequences in strings

[Rafael L. <ra...@la...>]

Sorry, I messed up with the Subject of my previous message. The 
Subject of this message is the correct one.

* Rafael Laboissière <ra...@de...> [2024-10-12 11:38]:

> Dear XMDS developers,
>
> Installation of the xmds2 package in Debian with a recent version of 
> Python (3.12, in my case), trigger these warnings:
>
>    Setting up xmds2 (3.1.0+dfsg2-8) ...
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/Tools/kde4.py:71: SyntaxWarning: invalid escape sequence '\s'
>      setregexp = re.compile('([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)')
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/Tools/qt4.py:257: SyntaxWarning: invalid escape sequence '\*'
>      """
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/lru_cache.py:19: SyntaxWarning: invalid escape sequence '\d'
>      re_num = re.compile('[a-zA-Z_-]+(\d+)')
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/lru_cache.py:43: SyntaxWarning: invalid escape sequence '\d'
>      re_num = re.compile('[a-zA-Z_]+(\d+)')
>    /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/misc.py:86: SyntaxWarning: invalid escape sequence '\w'
>      m4_re = re.compile('@(\w+)@', re.M)
>
> The patch attached to this message fixes the issue.
>
> Best,
>
> Rafael

> Description: Fix invalid escape sequences (in doctring and regex strings)
> Author: Rafael Laboissière <ra...@de...>
> Forwarded: no
> Last-Update: 2024-10-12
>
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/Tools/kde4.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/Tools/kde4.py 
> @@ -68,7 +68,7 @@ def configure(self): 
> 	fu = re.compile('#(.*)\n') 
> 	txt = fu.sub('', txt)
>
> -	setregexp = re.compile('([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)') 
> +	setregexp = re.compile(r'([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)') 
> 	found = setregexp.findall(txt)
>
> 	for (_, key, val) in found: 
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/Tools/qt4.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/Tools/qt4.py 
> @@ -262,11 +262,11 @@ def apply_qt4(self):
>
> 	The additional parameters are:
>
> -	:param lang: list of translation files (\*.ts) to process 
> +	:param lang: list of translation files (\\*.ts) to process 
> 	:type lang: list of :py:class:`waflib.Node.Node` or string without the .ts extension 
> -	:param update: whether to process the C++ files to update the \*.ts files (use **waf --translate**) 
> +	:param update: whether to process the C++ files to update the \\*.ts files (use **waf --translate**) 
> 	:type update: bool 
> -	:param langname: if given, transform the \*.ts files into a .qrc files to include in the binary file 
> +	:param langname: if given, transform the \\*.ts files into a .qrc files to include in the binary file 
> 	:type langname: :py:class:`waflib.Node.Node` or string without the .qrc extension 
> 	""" 
> 	if getattr(self, 'lang', None): 
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/extras/lru_cache.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/extras/lru_cache.py 
> @@ -16,7 +16,7 @@ Do export WAFCACHE=/tmp/foo_xyz where xy 
> If missing, the default cache size will be set to 10GB 
> """
>
> -re_num = re.compile('[a-zA-Z_-]+(\d+)') 
> +re_num = re.compile(r'[a-zA-Z_-]+(\d+)')
>
> CACHESIZE = 10*1024*1024*1024 # in bytes 
> CLEANRATIO = 0.8 
> @@ -40,7 +40,7 @@ def sweep(self): 
> 	CACHEDIR = Options.cache_global
>
> 	# get the cache max size from the WAFCACHE filename 
> -	re_num = re.compile('[a-zA-Z_]+(\d+)') 
> +	re_num = re.compile(r'[a-zA-Z_]+(\d+)') 
> 	val = re_num.sub('\\1', os.path.basename(Options.cache_global)) 
> 	try: 
> 		CACHESIZE = int(val) 
> --- xmds2-3.1.0+dfsg2.orig/xpdeint/waf/waflib/extras/misc.py 
> +++ xmds2-3.1.0+dfsg2/xpdeint/waf/waflib/extras/misc.py 
> @@ -83,7 +83,7 @@ def apply_copy(self): 
> def subst_func(tsk): 
> 	"Substitutes variables in a .in file"
>
> -	m4_re = re.compile('@(\w+)@', re.M) 
> +	m4_re = re.compile(r'@(\w+)@', re.M)
>
> 	code = tsk.inputs[0].read() #Utils.readf(infile)
>


> _______________________________________________ 
> xmds-devel mailing list 
> xmd...@li... 
> https://lists.sourceforge.net/lists/listinfo/xmds-devel

[xmds-devel] ss

[Rafael L. <ra...@de...>]

Dear XMDS developers,

Installation of the xmds2 package in Debian with a recent version of 
Python (3.12, in my case), trigger these warnings:

     Setting up xmds2 (3.1.0+dfsg2-8) ...
     /usr/lib/python3/dist-packages/xpdeint/waf/waflib/Tools/kde4.py:71: SyntaxWarning: invalid escape sequence '\s'
       setregexp = re.compile('([sS][eE][tT]\s*\()\s*([^\s]+)\s+\"([^"]+)\"\)')
     /usr/lib/python3/dist-packages/xpdeint/waf/waflib/Tools/qt4.py:257: SyntaxWarning: invalid escape sequence '\*'
       """
     /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/lru_cache.py:19: SyntaxWarning: invalid escape sequence '\d'
       re_num = re.compile('[a-zA-Z_-]+(\d+)')
     /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/lru_cache.py:43: SyntaxWarning: invalid escape sequence '\d'
       re_num = re.compile('[a-zA-Z_]+(\d+)')
     /usr/lib/python3/dist-packages/xpdeint/waf/waflib/extras/misc.py:86: SyntaxWarning: invalid escape sequence '\w'
       m4_re = re.compile('@(\w+)@', re.M)

The patch attached to this message fixes the issue.

Best,

Rafael

[xmds-devel] Drop useless imports

[Rafael L. <ra...@de...>]

Dear XMDS developers,

File xpdeint/waf/waflib/extras/clang_compilation_database.py makes two 
useless imports. The patch attached to this message fixes the issue.

Best,

Rafael Laboissière

[xmds-devel] Use importlib.resources instead of pkg_resources

[Rafael L. <ra...@de...>]

Dear XMDS developers,

Use of pkg_resources is deprecated in favor of importlib.resources, which 
was introduced in Python 3.9.

Please, find attached to this message a patches that is being currently 
applied to the Debian package xmds2. In order to put together this 
patch, I followed the recipe in https://setuptools.pypa.io/en/latest/pkg_resources.html

If you want to keep backward compatibility with Python < 3.9, you 
might use the importlib_resources package instead of importing 
importlib.resources.

Best,

Rafael Laboissière

[xmds-devel] XMDS fails to build against Python 3.12

[Rafael L. <ra...@de...>]

Dear XMDS developers,

The xmds2 package fails to build from source in the experimental 
distribution of Debian, in which Python has version 3.12: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061766

Indeed, the imp module, which was deprecated since version 3.4 of Python, 
has been removed in version 3.12.

The patch attached to this message fixes the problem for me. Apparently, 
imp.new_module() and types.ModuleType() have the same effect, so the 
patch replaces the former by the latter. With this patch, XMDS builds and 
all tests pass, against both versions 3.11 and 3.12 of Python.

Best regards,

Rafael Laboissière

Re: [xmds-devel] XMDS and h5py serial vs. mpi

[Rafael L. <ra...@de...>]

Hello,

Here is an update of the situation: a new version of the h5py package 
(3.9.0-4) has been uploaded to Debian unstable. In this version, 
h5py/__init__.py has been updated in order to enable fallback mechanism 
both ways: if h5py-serial is not installed then load h5py-mpi in serial 
jobs; if h5py-mpi is not installed than load h5py-serial in MPI jobs.

This fixes the issues that arose regarding the building of the xmds2 
package in Debian. A new version of the package (3.1.0+dfsg2-7) has been 
uploaded to unstable. This version has minimalistic (build-)dependencies 
on libhdf5-dev an python3-h5py (without explicit specification of serial 
vs. mpi variants).

In sum, this was a Debian-specific issue and there is nothing to do at 
the upstream side.

Best, 
  
Rafael Laboissière

* Rafael Laboissière <ra...@de...> [2023-10-13 09:03]:

> Thanks for your reply and clarifications, Mattias.
>
> You are right, everything works fine with only python3-h5py-serial as 
> the dependency. I do not remember the circumstances that lead to the 
> failure due to the lack of the MPI version of h5py.
>
> We are further investigating the issue and will eventually revert some 
> recent changes in the Debian xmds2 package, in order to simplify the 
> dependencies.
>
> Best,
>
> Rafael
>
> * Mattias Johnsson <mat...@mq...> [2023-10-12 02:54]:
>
>> Hi Rafael,
>>
>> I'm not that familiar with the test suite, but I can see no reason 
>> why it should need the MPI version of h5py. In fact, I see I've only 
>> got the python3-h5py-serial package installed on my machine, and 
>> everything seems fine.
>>
>> My understanding is that while MPI may be used for the simulation, 
>> the end result is a set of data files that are then processed 
>> serially using the xsil2graphics2 command, which is what uses the 
>> XSILFile.py code.
>>
>> That's certainly how end users will use it outside of the test suite anyway.
>>
>> Could you help me by explaining what tests are demanding the MPI 
>> version of h5py, and whether they would still be fine if they used 
>> the serial version instead? If this issue can be fixed simply by 
>> having XMDS2 only depend on python3-h5py-serial, that would seem to 
>> be the easiest solution.
>>
>> Regards, Mattias
>>
>> ________________________________ From: Rafael Laboissière 
>> <ra...@de...> Sent: Thursday, 12 October 2023 7:19 AM To: XMDS 
>> devel list <xmd...@li...> Cc: Nilesh Patra 
>> <ni...@ri...>; Drew Parsons <dpa...@de...> Subject: 
>> [xmds-devel] XMDS and h5py serial vs. mpi
>>
>> Dear XMDS developers,
>>
>> For some context in what follows, please see Bug#1053314, filed 
>> against the xmds2 package of the Debian distribution. 
>> https://bugs.debian.org/1053314<https://bugs.debian.org/1053314>
>>
>> This “bug” was caused by recent changes in the packaging for the 
>> h5py module for Python in Debian, as regards the serial and mpi 
>> variants. You can find more context on this here: https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian<https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian>
>>
>> Apparently, some of the tests in the unit tests suite of XMDS needs 
>> the MPI (not serial) version of h5py. Since h5py is accessed through 
>> the generic API in XSILFile.py, it may happen that the serial 
>> version h5py is used, instead of the MPI version. In order to “fix” 
>> the problem, I introduced the following patch to the xmds2 Debian 
>> package: https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch<https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch>
>>
>> The question we are asking ourselves regards the intentions of the 
>> XMDS upstream developers with h5py and MPI.
>>
>> I am adding Drew Parsons and Nilesh Patra in Cc to this message. 
>> They might wish to correct some of my assertions above or add 
>> comments on the issue.
>>
>> Best,
>>
>> Rafael Laboissière
>>
>>
>> _______________________________________________ xmds-devel mailing 
>> list xmd...@li... https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://lists.sourceforge.net/lists/listinfo/xmds-devel>
>

Re: [xmds-devel] XMDS and h5py serial vs. mpi

[Rafael L. <ra...@de...>]

Thanks for your reply and clarifications, Mattias.

You are right, everything works fine with only python3-h5py-serial as the 
dependency. I do not remember the circumstances that lead to the failure 
due to the lack of the MPI version of h5py.

We are further investigating the issue and will eventually revert some 
recent changes in the Debian xmds2 package, in order to simplify the 
dependencies.

Best,

Rafael

* Mattias Johnsson <mat...@mq...> [2023-10-12 02:54]:

> Hi Rafael,
>
> I'm not that familiar with the test suite, but I can see no reason why 
> it should need the MPI version of h5py. In fact, I see I've only got 
> the python3-h5py-serial package installed on my machine, and everything 
> seems fine.
>
> My understanding is that while MPI may be used for the simulation, the 
> end result is a set of data files that are then processed serially 
> using the xsil2graphics2 command, which is what uses the XSILFile.py 
> code.
>
> That's certainly how end users will use it outside of the test suite anyway.
>
> Could you help me by explaining what tests are demanding the MPI 
> version of h5py, and whether they would still be fine if they used the 
> serial version instead? If this issue can be fixed simply by having 
> XMDS2 only depend on python3-h5py-serial, that would seem to be the 
> easiest solution.
>
> Regards, 
> Mattias
>
> ________________________________ 
> From: Rafael Laboissière <ra...@de...> 
> Sent: Thursday, 12 October 2023 7:19 AM 
> To: XMDS devel list <xmd...@li...> 
> Cc: Nilesh Patra <ni...@ri...>; Drew Parsons <dpa...@de...> 
> Subject: [xmds-devel] XMDS and h5py serial vs. mpi
>
> Dear XMDS developers,
>
> For some context in what follows, please see Bug#1053314, filed against 
> the xmds2 package of the Debian distribution. 
> https://bugs.debian.org/1053314<https://bugs.debian.org/1053314>
>
> This “bug” was caused by recent changes in the packaging for the h5py 
> module for Python in Debian, as regards the serial and mpi variants. You 
> can find more context on this here: 
> https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian<https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian>
>
> Apparently, some of the tests in the unit tests suite of XMDS needs the 
> MPI (not serial) version of h5py. Since h5py is accessed through the 
> generic API in XSILFile.py, it may happen that the serial version h5py 
> is used, instead of the MPI version. In order to “fix” the problem, I 
> introduced the following patch to the xmds2 Debian package: 
> https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch<https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch>
>
> The question we are asking ourselves regards the intentions of the XMDS 
> upstream developers with h5py and MPI.
>
> I am adding Drew Parsons and Nilesh Patra in Cc to this message. They 
> might wish to correct some of my assertions above or add comments on the 
> issue.
>
> Best,
>
> Rafael Laboissière
>
>
> _______________________________________________ 
> xmds-devel mailing list 
> xmd...@li... 
> https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://lists.sourceforge.net/lists/listinfo/xmds-devel>

Re: [xmds-devel] XMDS and h5py serial vs. mpi

[Mattias J. <mat...@mq...>]

Hi Rafael,

I'm not that familiar with the test suite, but I can see no reason why it should need the MPI version of h5py. In fact, I see I've only got the python3-h5py-serial package installed on my machine, and everything seems fine.

My understanding is that while MPI may be used for the simulation, the end result is a set of data files that are then processed serially using the xsil2graphics2 command, which is what uses the XSILFile.py code.

That's certainly how end users will use it outside of the test suite anyway.

Could you help me by explaining what tests are demanding the MPI version of h5py, and whether they would still be fine if they used the serial version instead? If this issue can be fixed simply by having XMDS2 only depend on python3-h5py-serial, that would seem to be the easiest solution.

Regards,
Mattias

________________________________
From: Rafael Laboissière <ra...@de...>
Sent: Thursday, 12 October 2023 7:19 AM
To: XMDS devel list <xmd...@li...>
Cc: Nilesh Patra <ni...@ri...>; Drew Parsons <dpa...@de...>
Subject: [xmds-devel] XMDS and h5py serial vs. mpi

Dear XMDS developers,

For some context in what follows, please see Bug#1053314, filed against
the xmds2 package of the Debian distribution.
https://bugs.debian.org/1053314<https://bugs.debian.org/1053314>

This “bug” was caused by recent changes in the packaging for the h5py
module for Python in Debian, as regards the serial and mpi variants. You
can find more context on this here:
https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian<https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian>

Apparently, some of the tests in the unit tests suite of XMDS needs the
MPI (not serial) version of h5py. Since h5py is accessed through the
generic API in XSILFile.py, it may happen that the serial version h5py
is used, instead of the MPI version. In order to “fix” the problem, I
introduced the following patch to the xmds2 Debian package:
https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch<https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch>

The question we are asking ourselves regards the intentions of the XMDS
upstream developers with h5py and MPI.

I am adding Drew Parsons and Nilesh Patra in Cc to this message. They
might wish to correct some of my assertions above or add comments on the
issue.

Best,

Rafael Laboissière


_______________________________________________
xmds-devel mailing list
xmd...@li...
https://lists.sourceforge.net/lists/listinfo/xmds-devel<https://lists.sourceforge.net/lists/listinfo/xmds-devel>

[xmds-devel] XMDS and h5py serial vs. mpi

[Rafael L. <ra...@de...>]

Dear XMDS developers,

For some context in what follows, please see Bug#1053314, filed against 
the xmds2 package of the Debian distribution. 
https://bugs.debian.org/1053314

This “bug” was caused by recent changes in the packaging for the h5py 
module for Python in Debian, as regards the serial and mpi variants.  You 
can find more context on this here: 
https://salsa.debian.org/science-team/h5py/-/blob/master/debian/README.Debian

Apparently, some of the tests in the unit tests suite of XMDS needs the 
MPI (not serial) version of h5py. Since h5py is accessed through the 
generic API in XSILFile.py, it may happen that the serial version h5py 
is used, instead of the MPI version. In order to “fix” the problem, I 
introduced the following patch to the xmds2 Debian package: 
https://salsa.debian.org/science-team/xmds2/-/blob/master/debian/patches/h5py-always-use-mpi.patch

The question we are asking ourselves regards the intentions of the XMDS 
upstream developers with h5py and MPI.

I am adding Drew Parsons and Nilesh Patra in Cc to this message. They 
might wish to correct some of my assertions above or add comments on the 
issue.

Best,

Rafael Laboissière

Re: [xmds-devel] XMDS fails with version 1.23 of numpy

[Mattias J. <mat...@mq...>]

Patch tested and applied. Thanks Rafael, you're the best!

Cheers,
Mattias
________________________________
From: Rafael Laboissière <ra...@de...>
Sent: Wednesday, 21 December 2022 2:19 AM
To: XMDS devel list <xmd...@li...>
Subject: [xmds-devel] XMDS fails with version 1.23 of numpy

Dear XMDS developers,

XMDS2 fails when run against the latest version of numpy (1.23), with
errors like the following one:

   ERROR: test_breakpoints (__main__.main.<locals>.ScriptTestCase)
   io/breakpoints.xmds
   ----------------------------------------------------------------------
   Traceback (most recent call last):
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 328, in newfunc
       return func(*(args + fargs), **newkeywords)
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 189, in scriptTestingFunction
       results = XSILFile(resultsFullPath)
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 257, in __init__
       data = XSILDataBinary(independentVariables, dependentVariables, uLong, precision, encoding, filename,
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 99, in __init__
       if loadData: self.parseDataFile(uLong, precision, encoding, dataFile)
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 121, in parseDataFile
       independentGeometry.append(numpy.asscalar(size))
     File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 311, in __getattr__
       raise AttributeError("module {!r} has no attribute "
   AttributeError: module 'numpy' has no attribute 'asscalar'

The method numpy.asscalar() is deprecated since version 1.16 of numpy and
was removed in version 1.23.

The patch attached to this message fixes the problem.

Best,

Rafael Laboissière

[xmds-devel] XMDS fails with version 1.23 of numpy

[Rafael L. <ra...@de...>]

Dear XMDS developers,

XMDS2 fails when run against the latest version of numpy (1.23), with 
errors like the following one:

   ERROR: test_breakpoints (__main__.main.<locals>.ScriptTestCase)
   io/breakpoints.xmds
   ----------------------------------------------------------------------
   Traceback (most recent call last):
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 328, in newfunc
       return func(*(args + fargs), **newkeywords)
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/./run_tests.py", line 189, in scriptTestingFunction
       results = XSILFile(resultsFullPath)
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 257, in __init__
       data = XSILDataBinary(independentVariables, dependentVariables, uLong, precision, encoding, filename,
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 99, in __init__
       if loadData: self.parseDataFile(uLong, precision, encoding, dataFile)
     File "/var/data/rlaboiss/debian/PKGS/xmds2/xmds2/xpdeint/XSILFile.py", line 121, in parseDataFile
       independentGeometry.append(numpy.asscalar(size))
     File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 311, in __getattr__
       raise AttributeError("module {!r} has no attribute "
   AttributeError: module 'numpy' has no attribute 'asscalar'

The method numpy.asscalar() is deprecated since version 1.16 of numpy and 
was removed in version 1.23.

The patch attached to this message fixes the problem.

Best,

Rafael Laboissière

Re: [xmds-devel] Issues when building the documentation from source

[Rafael L. <ra...@de...>]

* Mattias Johnsson <mat...@mq...> [2022-11-04 22:52]:

> I guess that explains why I have a memory of occasional friendly_plus 
> errors in the past but could never reproduce them.
>
> I have tested your patch, and everything seems to work at my end as 
> well, so I have applied it.

Great, thanks!

You might also remove the files FriendlyPlusStyle.py and 
XMDSScriptLexer.py from the main XMDS code repository.

Best,

Rafael

Re: [xmds-devel] Issues when building the documentation from source

[Mattias J. <mat...@mq...>]

Thanks Rafael, nice detective work!

I guess that explains why I have a memory of occasional friendly_plus errors in the past but could never reproduce them.

I have tested your patch, and everything seems to work at my end as well, so I have applied it.

Thanks again!

Cheers,
Mattias
________________________________
From: Rafael Laboissière <ra...@de...>
Sent: Saturday, 5 November 2022 1:01 AM
To: Mattias Johnsson <mat...@mq...>; XMDS devel list <xmd...@li...>
Subject: Re: [xmds-devel] Issues when building the documentation from source

* Rafael Laboissière <ra...@de...> [2022-11-04 10:38]:
>
> I plunged deeper into the issue and I think I understand what is going
> on.  Indeed, there is a pygments.style entry point in setup.py that
> defines the friendly_plus style. This definition ends up in the
> entry_points.txt file of the main XMDS2 package:
>
>    $ cat /usr/lib/python3/dist-packages/xmds2-3.1.0.egg-info/entry_points.txt
>    [pygments.lexers]
>    XMDSScriptLexer = xpdeint.XMDSScriptLexer:XMDSScriptLexer
>
>    [pygments.styles]
>    friendly_plus = xpdeint.FriendlyPlusStyle:FriendlyPlusStyle
>
> This means that, in order to build the documentation, XMDS2 *must* be
> installed in the system. This is causing problems in the building of
> the xmds2 package for Debian, which is maintained by me.
>
> This is a strange setup. The xpdeint/FriendlyPlusStyle.py file has
> nothing to do with the XMDS2 package per se, since it is only used
> when building the documentation. The same remark applies to
> xpdeint/XMDSScriptLexer.py, BTW. These two files should be moved into
> the userdoc space and the entry points should be defined somehow
> there.
>
> Unfortunately, my knowledge of entry points and Pygments plugins is
> very scarce and I am unable to propose a quick and sound fix for this
> issue. I will try to take a look at it, as time permits.

I could “fix” the problem using the patch attached to this message. I
created a _pygments directory and copied the files FriendlyPlusStyle.py
and XMDSScriptLexer.py there. In conf.py, I replaced the line:

     pygments_style = 'friendly_plus'

by:

     sys.path.append(os.path.abspath("./_pygments"))
     pygments_style = 'FriendlyPlusStyle.FriendlyPlusStyle'
     extensions = ['XMDSScriptLexer']

Since XMDSScriptLexer.py is treated as a Sphinx extension, then it is
necessary to define a setup function in it:

     def setup(app):
       app.add_lexer('xmds2', XMDSScriptLexer)
       app.add_lexer('xpdeint', XMDSScriptLexer)

With this patch, it is possible to build the documentation without
having XMDS installed in the system.

Best,

Rafael

Re: [xmds-devel] Issues when building the documentation from source

[Rafael L. <ra...@de...>]

* Rafael Laboissière <ra...@de...> [2022-11-04 10:38]:
>
> I plunged deeper into the issue and I think I understand what is going 
> on.  Indeed, there is a pygments.style entry point in setup.py that 
> defines the friendly_plus style. This definition ends up in the 
> entry_points.txt file of the main XMDS2 package:
>
>    $ cat /usr/lib/python3/dist-packages/xmds2-3.1.0.egg-info/entry_points.txt
>    [pygments.lexers]
>    XMDSScriptLexer = xpdeint.XMDSScriptLexer:XMDSScriptLexer
>
>    [pygments.styles]
>    friendly_plus = xpdeint.FriendlyPlusStyle:FriendlyPlusStyle
>
> This means that, in order to build the documentation, XMDS2 *must* be 
> installed in the system. This is causing problems in the building of 
> the xmds2 package for Debian, which is maintained by me.
>
> This is a strange setup. The xpdeint/FriendlyPlusStyle.py file has 
> nothing to do with the XMDS2 package per se, since it is only used 
> when building the documentation. The same remark applies to 
> xpdeint/XMDSScriptLexer.py, BTW. These two files should be moved into 
> the userdoc space and the entry points should be defined somehow 
> there.
>
> Unfortunately, my knowledge of entry points and Pygments plugins is 
> very scarce and I am unable to propose a quick and sound fix for this 
> issue. I will try to take a look at it, as time permits.

I could “fix” the problem using the patch attached to this message. I 
created a _pygments directory and copied the files FriendlyPlusStyle.py 
and XMDSScriptLexer.py there. In conf.py, I replaced the line:

     pygments_style = 'friendly_plus'

by:

     sys.path.append(os.path.abspath("./_pygments"))
     pygments_style = 'FriendlyPlusStyle.FriendlyPlusStyle'
     extensions = ['XMDSScriptLexer']

Since XMDSScriptLexer.py is treated as a Sphinx extension, then it is 
necessary to define a setup function in it:

     def setup(app):
       app.add_lexer('xmds2', XMDSScriptLexer)
       app.add_lexer('xpdeint', XMDSScriptLexer)

With this patch, it is possible to build the documentation without 
having XMDS installed in the system.

Best,

Rafael

Re: [xmds-devel] Issues when building the documentation from source

[Rafael L. <ra...@de...>]

Hello Mattias,

* Mattias Johnsson <mat...@mq...> [2022-11-03 02:20]:

> Regarding the alignment tab, "&=&" on my machines works fine and 
> produces no warning. Strange. But "&=" also works, so I'm happy to 
> apply your patch. Thanks!

We have perhaps different versions of TeX-related packages in our 
systems, which is causing the divergent behavior. Thanks for applying the 
patch, anyway.

> Regarding friendly_plus, there is an "xpedient/FriendlyPlusStyle.py" 
> file that should define the style, so it seems your build is not 
> picking it up. However I don't understand the pygments system at all, 
> didn't write this bit, and have vague memories of friendly_plus errors 
> in the past that came and went. So if you can understand why this style 
> is not being picked up (again, it works when I build the docs on my 
> machines), that would be great to know. If you can't see why, I'll 
> consider applying your patch anyway and just use "friendly" since the 
> style difference is minor and just makes some of the XML examples in 
> the documentation easier to read.

I plunged deeper into the issue and I think I understand what is going 
on.  Indeed, there is a pygments.style entry point in setup.py that 
defines the friendly_plus style. This definition ends up in the 
entry_points.txt file of the main XMDS2 package:

     $ cat /usr/lib/python3/dist-packages/xmds2-3.1.0.egg-info/entry_points.txt
     [pygments.lexers]
     XMDSScriptLexer = xpdeint.XMDSScriptLexer:XMDSScriptLexer

     [pygments.styles]
     friendly_plus = xpdeint.FriendlyPlusStyle:FriendlyPlusStyle

This means that, in order to build the documentation, XMDS2 *must* be 
installed in the system. This is causing problems in the building of the 
xmds2 package for Debian, which is maintained by me.

This is a strange setup. The xpdeint/FriendlyPlusStyle.py file has 
nothing to do with the XMDS2 package per se, since it is only used when 
building the documentation. The same remark applies to 
xpdeint/XMDSScriptLexer.py, BTW. These two files should be moved into the 
userdoc space and the entry points should be defined somehow there.

Unfortunately, my knowledge of entry points and Pygments plugins is very 
scarce and I am unable to propose a quick and sound fix for this issue. I 
will try to take a look at it, as time permits.

Best,

Rafael

Re: [xmds-devel] Issues when building the documentation from source

[Mattias J. <mat...@mq...>]

Hi Rafael,

Regarding the alignment tab, "&=&" on my machines works fine and produces no warning. Strange. But "&=" also works, so I'm happy to apply your patch. Thanks!

Regarding friendly_plus, there is an "xpedient/FriendlyPlusStyle.py" file that should define the style, so it seems your build is not picking it up. However I don't understand the pygments system at all, didn't write this bit, and have vague memories of friendly_plus errors in the past that came and went. So if you can understand why this style is not being picked up (again, it works when I build the docs on my machines), that would be great to know. If you can't see why, I'll consider applying your patch anyway and just use "friendly" since the style difference is minor and just makes some of the XML examples in the documentation easier to read.

Cheers,
Mattias
________________________________
From: Rafael Laboissière <ra...@de...>
Sent: Thursday, 3 November 2022 12:09 PM
To: XMDS devel list <xmd...@li...>
Subject: [xmds-devel] Issues when building the documentation from source

Dear XMDS developers,

Building the XMDS documentation from source [*] fails with these two
unrelated errors:

1) Non existent pygments style

This is the error message:

python3 -msphinx -b html -d ../../documentation/doctrees . ../../documentation
Running Sphinx v4.5.0

Exception occurred:
File "/usr/lib/python3/dist-packages/pygments/styles/__init__.py", line 80, in get_style_by_name
raise ClassNotFound("Could not find style module %r" % mod +
pygments.util.ClassNotFound: Could not find style module 'friendly_plus'.

Indeed, the style 'friendly_plus' does ot exist:

$ python3
Python 3.10.7 (main, Oct 1 2022, 04:31:04) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pygments.styles import STYLE_MAP
>>> STYLE_MAP.keys()
dict_keys(['default', 'emacs', 'friendly', 'friendly_grayscale', 'colorful', 'autumn', 'murphy', 'manni', 'material', 'monokai', 'perldoc', 'pastie', 'borland', 'trac', 'native', 'fruity', 'bw', 'vim', 'vs', 'tango', 'rrt', 'xcode', 'igor', 'paraiso-light', 'paraiso-dark', 'lovelace', 'algol', 'algol_nu', 'arduino', 'rainbow_dash', 'abap', 'solarized-dark', 'solarized-light', 'sas', 'stata', 'stata-light', 'stata-dark', 'inkpot', 'zenburn', 'gruvbox-dark', 'gruvbox-light', 'dracula', 'one-dark', 'lilypond'])

The patch pygments-style.patch attached to this message fixes the
problem.

2) Alignment tab in LaTeX split environment

When build the PDF form of the documentation, I came across this error:

$ make -C documentation/latex all-pdf
[…]
[62]
! Extra alignment tab has been changed to \cr.
<template> }$\hfill \endtemplate
l.3231 ...t](r) \right\} e^{i m \theta}\end{split}

This is caused by the presence of "&=&" instead of "&=" in the
mathematical formulae in reference_elements.rst.

The patch extra-alignment-tab.patch attached to this message fixes the
problem.

Best regards,

Rafael Laboissière

[*] from the sources obtained from SVN https://sourceforge.net/p/xmds/code/HEAD/tree/trunk/xpdeint/admin/userdoc-source/<https://sourceforge.net/p/xmds/code/HEAD/tree/trunk/xpdeint/admin/userdoc-source>

[xmds-devel] Issues when building the documentation from source

[Rafael L. <ra...@de...>]

Dear XMDS developers,

Building the XMDS documentation from source [*] fails with these two 
unrelated errors:

1) Non existent pygments style

This is the error message:

     python3 -msphinx -b html -d ../../documentation/doctrees   . ../../documentation
     Running Sphinx v4.5.0

     Exception occurred:
       File "/usr/lib/python3/dist-packages/pygments/styles/__init__.py", line 80, in get_style_by_name
         raise ClassNotFound("Could not find style module %r" % mod +
     pygments.util.ClassNotFound: Could not find style module 'friendly_plus'.

Indeed, the style 'friendly_plus' does ot exist:

     $ python3
     Python 3.10.7 (main, Oct  1 2022, 04:31:04) [GCC 12.2.0] on linux
     Type "help", "copyright", "credits" or "license" for more information.
>>> from pygments.styles import STYLE_MAP 
>>> STYLE_MAP.keys()
     dict_keys(['default', 'emacs', 'friendly', 'friendly_grayscale', 'colorful', 'autumn', 'murphy', 'manni', 'material', 'monokai', 'perldoc', 'pastie', 'borland', 'trac', 'native', 'fruity', 'bw', 'vim', 'vs', 'tango', 'rrt', 'xcode', 'igor', 'paraiso-light', 'paraiso-dark', 'lovelace', 'algol', 'algol_nu', 'arduino', 'rainbow_dash', 'abap', 'solarized-dark', 'solarized-light', 'sas', 'stata', 'stata-light', 'stata-dark', 'inkpot', 'zenburn', 'gruvbox-dark', 'gruvbox-light', 'dracula', 'one-dark', 'lilypond'])

The patch pygments-style.patch attached to this message fixes the 
problem.

2) Alignment tab in LaTeX split environment

When build the PDF form of the documentation, I came across this error:

     $ make -C documentation/latex all-pdf
     […]
     [62]
     ! Extra alignment tab has been changed to \cr.
     <template> }$\hfill \endtemplate
     l.3231 ...t](r) \right\} e^{i m \theta}\end{split}

This is caused by the presence of "&=&" instead of "&=" in the 
mathematical formulae in reference_elements.rst.

The patch extra-alignment-tab.patch attached to this message fixes the 
problem.

Best regards,

Rafael Laboissière

[*] from the sources obtained from SVN https://sourceforge.net/p/xmds/code/HEAD/tree/trunk/xpdeint/admin/userdoc-source/

[xmds-devel] Fix unit tests on Debian with GCC 11.2.0

[Mattias J. <mat...@mq...>]

Some unit tests were failing when the generated C++ file is compiled
against GCC 11.2.0 on a Debian system. The problems are related to
name clashes between global variables are library functions
(namely "beta" and "size"), so rename those variables in the
xmds scripts.

Patch contributed by Rafael Laboissière fixing the issue is copied below:

Description: Avoid clash between global variables and library functions
Author: Rafael Laboissière <ra...@de...>
Bug-Debian: https://bugs.debian.org/996279
Forwarded: no
Last-Update: 2021-10-19

--- xmds2-3.0.0+dfsg.orig/testsuite/features/arguments.xmds
+++ xmds2-3.0.0+dfsg/testsuite/features/arguments.xmds
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <simulation xmds-version="2">
   <testing>
-    <arguments>--time_factor 2.0 --size 25.0</arguments>
+    <arguments>--time_factor 2.0 --ssize 25.0</arguments>
     <xsil_file name="arguments.xsil" expected="arguments_expected.xsil" absolute_tolerance="1e-7" relative_tolerance="1e-5" />
   </testing>

@@ -10,7 +10,7 @@
   <description>
     Simple one-dimensional diffusion with a pointless second dimension thrown in for fun.
     Uses arguments and argument preprocessing. Essentially the simulation "looks" the
-    same for any given "size", as the interval/etc is scaled to fit the interesting region.
+    same for any given "ssize", as the interval/etc is scaled to fit the interesting region.
     The user may use width_scale, time_scale and ratio to zoom out and in...
   </description>

@@ -29,16 +29,16 @@
       ]]>
     </globals>
     <arguments>
-      <argument name="size" type="real" default_value="20.0"/>
+      <argument name="ssize" type="real" default_value="20.0"/>
       <argument name="fraction" type="real" default_value="0.1"/>
       <argument name="width_factor" type="real" default_value="1.0"/>
       <argument name="time_factor" type="real" default_value="1.0"/>
       <![CDATA[
-      minx = -0.5*size;
-      maxx = 0.5*size;
-      miny = -0.5*size*fraction;
-      maxy = 0.5*size*fraction;
-      width = 0.5*sqrt(0.5)*size*fraction*width_factor; // half the simulation size
+      minx = -0.5*ssize;
+      maxx = 0.5*ssize;
+      miny = -0.5*ssize*fraction;
+      maxy = 0.5*ssize*fraction;
+      width = 0.5*sqrt(0.5)*ssize*fraction*width_factor; // half the simulation size
       // The time intersting stuff happens scales as width^2
       time_interval = 20.0 * width*width * time_factor;
       ]]>
--- xmds2-3.0.0+dfsg.orig/testsuite/features/space in filename.xmds
+++ xmds2-3.0.0+dfsg/testsuite/features/space in filename.xmds
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <simulation xmds-version="2">
   <testing>
-    <arguments>--time_factor 2.0 --size 25.0</arguments>
+    <arguments>--time_factor 2.0 --ssize 25.0</arguments>
     <xsil_file name="space in filename.xsil" expected="arguments_expected.xsil" absolute_tolerance="1e-7" relative_tolerance="1e-5" />
   </testing>

@@ -12,7 +12,7 @@

     Simple one-dimensional diffusion with a pointless second dimension thrown in for fun.
     Uses arguments and argument preprocessing. Essentially the simulation "looks" the
-    same for any given "size", as the interval/etc is scaled to fit the interesting region.
+    same for any given "ssize", as the interval/etc is scaled to fit the interesting region.
     The user may use width_scale, time_scale and ratio to zoom out and in...
   </description>

@@ -31,16 +31,16 @@
       ]]>
     </globals>
     <arguments>
-      <argument name="size" type="real" default_value="20.0"/>
+      <argument name="ssize" type="real" default_value="20.0"/>
       <argument name="fraction" type="real" default_value="0.1"/>
       <argument name="width_factor" type="real" default_value="1.0"/>
       <argument name="time_factor" type="real" default_value="1.0"/>
       <![CDATA[
-      minx = -0.5*size;
-      maxx = 0.5*size;
-      miny = -0.5*size*fraction;
-      maxy = 0.5*size*fraction;
-      width = 0.5*sqrt(0.5)*size*fraction*width_factor; // half the simulation size
+      minx = -0.5*ssize;
+      maxx = 0.5*ssize;
+      miny = -0.5*ssize*fraction;
+      maxy = 0.5*ssize*fraction;
+      width = 0.5*sqrt(0.5)*ssize*fraction*width_factor; // half the simulation size
       // The time intersting stuff happens scales as width^2
       time_interval = 20.0 * width*width * time_factor;
       ]]>
--- xmds2-3.0.0+dfsg.orig/testsuite/mpi/fibre_integer_dimensions_mpi.xmds
+++ xmds2-3.0.0+dfsg/testsuite/mpi/fibre_integer_dimensions_mpi.xmds
@@ -28,7 +28,7 @@
     <globals>
       <![CDATA[
       const real ggamma = 1.0;
-      const real beta = sqrt(4.0*M_PI*ggamma/10.0);
+      const real bbeta = sqrt(4.0*M_PI*ggamma/10.0);
       ]]>
     </globals>
   </features>
@@ -59,7 +59,7 @@
         <integration_vectors>main</integration_vectors>
         <dependencies>noise</dependencies>
         <![CDATA[
-          dphi_dt = L[phi] - ggamma*phi + beta*n_1;
+          dphi_dt = L[phi] - ggamma*phi + bbeta*n_1;
         ]]>
       </operators>
     </integrate>
--- xmds2-3.0.0+dfsg.orig/testsuite/stochastic/fibre.xmds
+++ xmds2-3.0.0+dfsg/testsuite/stochastic/fibre.xmds
@@ -22,7 +22,7 @@
     <globals>
       <![CDATA[
       const real ggamma = 1.0;
-      const real beta = sqrt(4.0*M_PI*ggamma/10.0);
+      const real bbeta = sqrt(4.0*M_PI*ggamma/10.0);
       ]]>
     </globals>
   </features>
@@ -53,7 +53,7 @@
         <integration_vectors>main</integration_vectors>
         <dependencies>noise</dependencies>
         <![CDATA[
-          dphi_dt = L[phi] - ggamma*phi + beta*n_1;
+          dphi_dt = L[phi] - ggamma*phi + bbeta*n_1;
         ]]>
       </operators>
     </integrate>
--- xmds2-3.0.0+dfsg.orig/testsuite/stochastic/fibre_with_correlation_functions.xmds
+++ xmds2-3.0.0+dfsg/testsuite/stochastic/fibre_with_correlation_functions.xmds
@@ -23,7 +23,7 @@
     <globals>
       <![CDATA[
       const real ggamma = 1.0;
-      const real beta = sqrt(4.0*M_PI*ggamma/10.0);
+      const real bbeta = sqrt(4.0*M_PI*ggamma/10.0);
       ]]>
     </globals>
   </features>
@@ -54,7 +54,7 @@
         <integration_vectors>main</integration_vectors>
         <dependencies>noise</dependencies>
         <![CDATA[
-          dphi_dt = L[phi] - ggamma*phi + beta*n_1;
+          dphi_dt = L[phi] - ggamma*phi + bbeta*n_1;
         ]]>
       </operators>
     </integrate>

[xmds-devel] Unit tests failure with GCC 11

[Rafael L. <ra...@de...>]

Dear XMDS developers,

Some unit tests are failing when the generated C++ file is compiled 
against GCC 11.2.0 on a Debian system. The full log of the compilation 
failures is attached to this message.

Also attached is a patch for fixing the problem, which is currently 
applied to the Debian package xmds2.  This is necessary, since the build 
of the Debian package exercises the unit tests.

All the five problems are related to name clashes between global 
variables are library functions (namely "beta" and "size").

Best regards,

Rafael Laboissière

Re: [xmds-devel] [xmds-user] issue regarding interpreting result of non linear Schrodinger equation

[Mattias J. <mat...@mq...>]

Hi Bandita,

I'm assuming you're using the "nlse.xmds" script that comes as one of the examples. After compiling and running the script with

xmds2 nlse.xmds
./nlse

you will have a data file "nlse.h5" which contains your output formatted in the HDF5 standard, as well as a description of that data and the original problem called "nlse.xsil". You can use "nlse.h5" with any standard programs that can handle HDF5 data. If you specifically want to use the data in Mathematica, XMDS2 provides a helper program "xsil2graphics2". If you run

xsil2graphics2 -e nlse.xsil

it will produce a file called "nlse.nb" that you can load as a Mathematica notebook. Note that the "-e" option creates a Mathematica notebook, if you use the "-m" option it will create an import script for Matlab and so on. "xsil2graphics2 --help" will give you a list of all the options.

Once you have loaded the "nlse.nb" notebook in Mathematica and run it, you will have all the data as the variables {"xi1", "tau1", "density1", "xi2", "normalisation2", "xi3", "ktau3", "densityK3"}. These are the moments you defined in your output moment groups, with the number on the end corresponding to the moment group.

Once you have this data you can plot it however you like. For example

ListPlot3D[density1, DataRange -> {{-6, 6}, {0, 20}},  PlotRange -> All]

will plot the full density function.

Cheers,
Mattias
________________________________
From: bandita das <ban...@uo...>
Sent: Monday, 6 April 2020 12:47 AM
To: xmd...@li... <xmd...@li...>
Subject: [xmds-user] issue regarding interpreting result of non linear Schrodinger equation

Dear Sir,

I am having an issue interpreting the output of the nlse.xmds file.
My problem is regarding extracting it to mathematica and plotting the density function with respect to the transverse dimension. Will you please help me out with this. I am very new to coding, so I'm not getting it very clearly.

--
Bandita Das,
Research scholar,
School of Physics,
University of Hyderabad,
CR Rao Road, Gachibowli, 500046.

Re: [xmds-devel] Executable file in /usr/lib

[Mattias J. <mat...@mq...>]

Hi Rafael,

Thanks for the patch, but I've already fixed this in the development version of the code!

Cheers,
Mattias

________________________________
From: Rafael Laboissière <ra...@de...>
Sent: Monday, 30 March 2020 5:57 PM
To: XMDS devel list <xmd...@li...>
Subject: [xmds-devel] Executable file in /usr/lib

Dear XMDS developers,

Attached below is a patch for fixing the the following warning with
the recent version of h5py:

  H5pyDeprecationWarning: dataset.value has been deprecated. Use dataset[()] instead.

Best regards,

Rafael Laboissière

[xmds-devel] Executable file in /usr/lib

[Rafael L. <ra...@de...>]

Dear XMDS developers,

Attached below is a patch for fixing the the following warning with 
the recent version of h5py:

  H5pyDeprecationWarning: dataset.value has been deprecated. Use dataset[()] instead.

Best regards,

Rafael Laboissière