Re: Need information regarding the Apache airflow server down

[Jed Cunningham]

Hi Nikhil,

What "Airflow server" are you referring to? I'm not aware of anything that
the community provides being down currently.

Did you mean to send this to $work, not the community, perhaps?

Jed

Re: [petsc-users] DMPlex periodic face coordinates

[Jed Brown]

 Matteo Semplice  writes: >> The way that periodic coordinates work is that it stores a DG >> coordinate field by cell. Faces default back to the vertices. You >> could think about  also




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Matteo Semplice  writes:

>> The way that periodic coordinates work is that it stores a DG 
>> coordinate field by cell. Faces default back to the vertices. You 
>> could think about  also putting DG coordinates on faces, but no one 
>> had asked, and it is potentially expensive.
>>
>> If you really need them to keep going, face coordinates can be 
>> extracted from cell coordinates. Otherwise, I can do it after the 
>> PETSc Meeting. Or, we are happy to take contributions adding this.
>
> Hi.
>
> I mainly wanted to check that this was expected and not a result of a 
> setup of my DM. No need to change Petsc now except maybe issuing a 
> warning if the fallback to continuous coordinates will give wrong 
> results. As for my code, I think I can extract the info from the cell 
> coordinates in a pre-processing phase and if this crazy FV methods I am 
> implementing will survive for long enough, I'll think about contributing.

You can also check out the "isoperiodic" example (src/dm/impls/plex/tests/ex49.c) if you want the semantic that donor and image points are separate points that map to the same global dofs. This avoids having any "DG coordinate field".

Re: [VOTE] Proposal for adding Telemetry via Scarf

[Jed Cunningham]

+1 binding

Re: [VOTE] Release Airflow 2.9.1 from 2.9.1rc2

[Jed Cunningham]

+1 (binding)

Checked reproducibility, signatures, checksums, licences. Used it with the
helm chart with a few different configs.

Re: [HUGE DISCUSSION] Airflow3 and tactical (Airflow 2) vs strategic (Airflow 3) approach

[Jed Cunningham]

Very exciting! Looks like we will have a busy period of time ahead of us.
Overall I like the plan so far, especially using this year's Airflow Summit
as an opportunity to announce and gather feedback, and the 2025 version to
pitch upgrading.

I left a comment in the doc, but we might want to iterate on the
terminology we use for high priority or "synchronous" DAG runs to serve LLM
responses - I find "interactive DAG runs" a bit confusing.

[ANNOUNCE] Apache Airflow Python Client 2.9.0 Released

[Jed Cunningham]

Dear Airflow community,

I'm happy to announce that Apache Airflow Python Client 2.9.0 was just
released.

We made this version available on PyPI for convenience:
`pip install apache-airflow-client`
https://pypi.org/project/apache-airflow-client/2.9.0/

The documentation is available at:
https://github.com/apache/airflow-client-python/

Find the changelog here for more details:
https://github.com/apache/airflow-client-python/blob/main/CHANGELOG.md

Thanks,
Jed

[ANNOUNCE] Apache Airflow Python Client 2.9.0 Released

[Jed Cunningham]

Dear Airflow community,

I'm happy to announce that Apache Airflow Python Client 2.9.0 was just
released.

We made this version available on PyPI for convenience:
`pip install apache-airflow-client`
https://pypi.org/project/apache-airflow-client/2.9.0/

The documentation is available at:
https://github.com/apache/airflow-client-python/

Find the changelog here for more details:
https://github.com/apache/airflow-client-python/blob/main/CHANGELOG.md

Thanks,
Jed

[RESULT][VOTE] Release Apache Airflow Python Client 2.9.0 from 2.9.0rc1

[Jed Cunningham]

Hello,

Apache Airflow Python Client 2.9.0 (based on RC1) has been accepted.

4 "+1" binding votes received:
- Jed Cunningham
- Jarek Potiuk
- Kaxil Naik
- Hussein Awala

2 "+1" non-binding votes received:

- Pankaj Koti
- Amogh Desai

Vote thread:
https://lists.apache.org/thread/okybvk22mzzskflz8vbkvrd07cgj38gw

I'll continue with the release process, and the release announcement will
follow shortly.

Thanks,
Jed

[Vo]:ICCF24 proceedings uploaded

[Jed Rothwell]

See:

JOURNAL OF CONDENSED MATTER NUCLEAR SCIENCE

Experiments and Methods in Cold Fusion

Proceedings of ICCF24 Solid State Energy Summit, Mountain View, California,
July 25–28, 2022

VOLUME 38, May 2024

https://lenr-canr.org/acrobat/BiberianJPjcondensedzk.pdf




I have not added this title or individual papers to the index. That will
take a while. I figured readers here will want to see this now.

- Jed

Re: [VOTE] April 2024 PR of the Month

[Jed Cunningham]

I'll also vote for 38674 - cool stuff!

Re: [petsc-dev] Error creating DMPlex from CGNS file

[Jed Brown]

 Thanks for fixing this issue. To contribute, the standard practice is to make a fork and push there. https: //urldefense. us/v3/__https: //gitlab. com/petsc/petsc/-/forks/new__;!!G_uCfscf7eWS!dT8V-NZ0-KPA3SkO_ZJ7HqQVqnCB0IftBhmT_RQAaVE2s3mVhMzzLkDDiw1LV3RyVSXBuH5a7Dk9JZVDoAA$




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Thanks for fixing this issue. To contribute, the standard practice is to make a fork and push there.

https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/forks/new__;!!G_uCfscf7eWS!dT8V-NZ0-KPA3SkO_ZJ7HqQVqnCB0IftBhmT_RQAaVE2s3mVhMzzLkDDiw1LV3RyVSXBuH5a7Dk9JZVDoAA$
https://urldefense.us/v3/__https://petsc.org/main/developers/contributing/__;!!G_uCfscf7eWS!dT8V-NZ0-KPA3SkO_ZJ7HqQVqnCB0IftBhmT_RQAaVE2s3mVhMzzLkDDiw1LV3RyVSXBuH5a7Dk9GCmXq6M$

Ravindra Chopade  writes:

> Hi Matt,
>
> I have fixed this issue locally, I have created an account on gitlab with
> username "rchopade". I can't push my bug fix branch to the Petsc project as
> I dont have access to push the code.
>
> How should I request access ? Can someone help me with this?
>
> Thanks
> Ravi
>
> On Sat, Apr 27, 2024 at 11:12 PM Matthew Knepley  wrote:
>
>> On Sat, Apr 27, 2024 at 8:35 AM Ravindra Chopade 
>> wrote:
>>
>>> Hi Matt,
>>>
>>> I am getting the same error with the latest version of PETSc.
>>>
>>
>> Shoot, that is right. Multiple zones was done, but not multiple sections.
>> Honestly, I do not understand
>> what the idea behind multiple sections is.
>>
>>
>>> Is there another way where I can import mesh from SALOME.
>>>
>>
>> Not if it uses multiple sections. If you can tell me what they are
>> actually doing with that, maybe the code
>> can be fixed.
>>
>>   Thanks,
>>
>> Matt
>>
>>
>>> Thanks
>>> Ravi
>>>
>>>
>>> On Mon, Apr 15, 2024 at 4:49 AM Matthew Knepley 
>>> wrote:
>>>
 On Sun, Apr 14, 2024 at 2:14 PM Ravindra Chopade <
 ravichopad...@gmail.com> wrote:

> Hello All, I have exported mesh in cgns format from SALOME, I am trying
> to create a DMPlex object from the exported CGNS file, I am getting below
> error. Can someone help me to fix this issue ? Note- I am using PETSc
> version 3. 16. 0 because it
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
> Hello All,
>
> I have exported mesh in cgns format from SALOME, I am trying to create
> a DMPlex object from the exported CGNS file, I am getting below error. Can
> someone help me to fix this issue ?
>
> Note- I am using PETSc version 3.16.0 because it is compatible with
> cgns and hdf version distributed with SALOME
>

 This is a limitation of PETSc 3.16. Could you try the latest version and
 let us know if problems happen  there?

   Thanks,

 Matt


> [0]PETSC ERROR: - Error Message
> --
> [0]PETSC ERROR: Error in external library
> [0]PETSC ERROR: CGNS file must have a single section, not 3
>
> [0]PETSC ERROR: See https://urldefense.us/v3/__https://petsc.org/release/faq/__;!!G_uCfscf7eWS!dPo_TlNT20yjdiDZ3UbAnxhEszvNKx9VHng-1QQ2F1YYC6lmM-Oz5SuT1HifOsS373-W9T_fJL97S3gRuQC5rvpmPORb$
> 
>for trouble shooting.
> [0]PETSC ERROR: Petsc Release Version 3.16.0, unknown
> [0]PETSC ERROR: ./my_ex2 on a arch-linux2-c-debug named
> ravindra-Lenovo-G50-80 by ravindra Sun Apr 14 23:35:02 2024
> [0]PETSC ERROR: Configure options
> --with-hdf5-dir=/home/ravindra/ThirdParty/SALOME-9.12.0/BINARIES-CO7/hdf5
> --with-cgns-dir=/home/ravindra/ThirdParty/SALOME-9.12.0/BINARIES-CO7/cgns
> --download-ctetgen
> [0]PETSC ERROR: #1 DMPlexCreateCGNS() at
> /home/ravindra/users/PETscDev/petsc/src/dm/impls/plex/plexcgns.c:162
> [0]PETSC ERROR: #2 DMPlexCreateCGNSFromFile() at
> /home/ravindra/users/PETscDev/petsc/src/dm/impls/plex/plexcgns.c:57
> [0]PETSC ERROR: #3 main() at my_ex2.c:23
> [0]PETSC ERROR: No PETSc Option Table entries
> [0]PETSC ERROR: End of Error Message ---send entire
> error message to petsc-ma...@mcs.anl.gov--
>
> --
>
> Thanks
> Ravi Chopade
>


 --
 What most experimenters take for granted before they begin their
 experiments is infinitely more interesting than any results to which their
 experiments lead.
 -- Norbert Wiener

 

Re: [petsc-users] About recent changes in GAMG

[Jed Brown]

 Ashish Patel  writes: > Hi Jed, > VmRss is on a higher side and seems to match what PetscMallocGetMaximumUsage is reporting. HugetlbPages was 0 for me. > > Mark, running without the near nullspace also




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Ashish Patel  writes:

> Hi Jed,
> VmRss is on a higher side and seems to match what PetscMallocGetMaximumUsage is reporting. HugetlbPages was 0 for me.
>
> Mark, running without the near nullspace also gives similar results. I have attached the malloc_view and gamg info for serial and 2 core runs. Some of the standout functions on rank 0 for parallel run seems to be
> 5.3 GB MatSeqAIJSetPreallocation_SeqAIJ
> 7.7 GB MatStashSortCompress_Private
> 10.1 GB PetscMatStashSpaceGet
> 7.7 GB  PetscSegBufferAlloc_Private
>
> malloc_view also says the following
> [0] Maximum memory PetscMalloc()ed 32387548912 maximum size of entire process 8270635008
> which fits the PetscMallocGetMaximumUsage > PetscMemoryGetMaximumUsage output.

This would occur if there was a large PetscMalloc'd block that did not get used (so only a portion of it is faulted and thus becomes resident).

Can you run a heap profiler like heaptrack?

https://urldefense.us/v3/__https://github.com/KDE/heaptrack__;!!G_uCfscf7eWS!df4YJk0DTT-nhR7waR508BVDCwjsXjQWK-Ng4rwx9hY2N6Wzg-qLoMvB5seh4A-GpnUIad0xjnCKheATOMQ$

[VOTE] Release Apache Airflow Python Client 2.9.0 from 2.9.0rc1

[Jed Cunningham]

Hey fellow Airflowers,

I have cut the first release candidate for the Apache Airflow Python Client
2.9.0.
This email is calling for a vote on the release,
which will last for 72 hours. Consider this my (binding) +1.

Airflow Client 2.9.0rc1 is available at:
https://dist.apache.org/repos/dist/dev/airflow/clients/python/2.9.0rc1/

The apache_airflow_client-2.9.0.tar.gz is an sdist release that contains
INSTALL instructions, and also is the official source release.

The apache_airflow_client-2.9.0-py3-none-any.whl is a binary wheel release
that pip can install.

Those packages do not contain .rc* version as, when approved, they will be
released as the final version.

The rc packages are also available at PyPI (with rc suffix) and you can
install it with pip as usual:
https://pypi.org/project/apache-airflow-client/2.9.0rc1/

Public keys are available at:
https://dist.apache.org/repos/dist/release/airflow/KEYS

Only votes from PMC members are binding, but all members of the community
are encouraged to test the release and vote with "(non-binding)".

The test procedure for PMC members is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PYTHON_CLIENT.md#verify-the-release-candidate-by-pmc-members

The test procedure for contributors and members of the community who would
like to test this RC is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PYTHON_CLIENT.md#verify-the-release-candidate-by-contributors

*Changelog:*

*Major changes:*

- Allow users to write dag_id and task_id in their national characters,
added display name for dag / task (v2) (#38446)
- Add dataset_expression to grid dag details (#38121)
- Adding run_id column to log table (#37731)
- Show custom instance names for a mapped task in UI (#36797)
- Add excluded/included events to get_event_logs api (#37641)
- Filter Datasets by associated dag_ids (GET /datasets) (#37512)
- Add data_interval_start and data_interval_end in dagrun create API
endpoint (#36630)
- Return the specified field when get dag/dagRun (#36641)

*New API supported:*

- Add post endpoint for dataset events (#37570)
- Add "queuedEvent" endpoint to get/delete DatasetDagRunQueue (#37176)

Thanks,
Jed

Re: [petsc-users] About recent changes in GAMG

[Jed Brown]

 Mark Adams  writes: >>> Yea, my interpretation of these methods is also that " > PetscMemoryGetMaximumUsage" should be >= "PetscMallocGetMaximumUsage". >>> But you are seeing the opposite. >




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Mark Adams  writes:

>>> Yea, my interpretation of these methods is also that "
> PetscMemoryGetMaximumUsage" should be >= "PetscMallocGetMaximumUsage".
>>> But you are seeing the opposite.
>
>
> We are using PETSc main and have found a case where memory consumption
> explodes in parallel.
> Also, we see a non-negligible difference between PetscMemoryGetMaximumUsage()
> and PetscMallocGetMaximumUsage().
> Running in serial through /usr/bin/time, the max. resident set size matches
> the PetscMallocGetMaximumUsage() result.
> I would have expected it to match PetscMemoryGetMaximumUsage() instead.

PetscMemoryGetMaximumUsage uses procfs (if PETSC_USE_PROCFS_FOR_SIZE, which should be typical on Linux anyway) in PetscHeaderDestroy to update a static variable. If you haven't destroyed an object yet, its value will be nonsense.

If your program is using huge pages, it might also be inaccurate (I don't know). You can look at /proc//statm to see what PETSc is reading (second field, which is number of pages in RSS). You can also look at the VmRss field in /proc//status, which reads in kB. See also the HugetlbPages field in /proc//status.

https://urldefense.us/v3/__https://www.kernel.org/doc/Documentation/filesystems/proc.txt__;!!G_uCfscf7eWS!cYQAqCnRrQFd88xpw8saPLzcLreaIydq44usKHYWNQNFwgqzphcVllTxRitP8YlISeT_6P19CASqdU5NqnA$

If your app is swapping, these will be inaccurate because swapped memory is not resident. We don't use the first field (VmSize) because there are reasons why programs sometimes map much more memory than they'll actually use, making such numbers irrelevant for most purposes.

>
>
> PetscMemoryGetMaximumUsage
> PetscMallocGetMaximumUsage
>  Time
> Serial + Option 1
>  4.8 GB
>  7.4 GB
> 112 sec
> 2 core + Option1
> 15.2 GB
> 45.5 GB
> 150 sec
> Serial + Option 2
> 3.1 GB
> 3.8 GB
>  167 sec
> 2 core + Option2
> 13.1 GB
> 17.4 GB
> 89 sec
> Serial + Option 3
> 4.7GB
> 5.2GB
> 693 sec
> 2 core + Option 3
> 23.2 GB
> 26.4 GB
> 411 sec
>
>
> On Thu, Apr 18, 2024 at 4:13 PM Mark Adams  wrote:
>
>> The next thing you might try is not using the null space argument.
>> Hypre does not use it, but GAMG does.
>> You could also run with -malloc_view to see some info on mallocs. It is
>> probably in the Mat objects.
>> You can also run with "-info" and grep on GAMG in the output and send that.
>>
>> Mark
>>
>> On Thu, Apr 18, 2024 at 12:03 PM Ashish Patel 
>> wrote:
>>
>>> Hi Mark,
>>>
>>> Thanks for your response and suggestion. With hypre both memory and time
>>> looks good, here is the data for that
>>>
>>> PetscMemoryGetMaximumUsage
>>> PetscMallocGetMaximumUsage
>>>  Time
>>> Serial + Option 4
>>> 5.55 GB
>>>  5.17 GB
>>> 15.7 sec
>>> 2 core + Option 4
>>> 5.85 GB
>>> 4.69 GB
>>> 21.9 sec
>>>
>>> Option 4
>>> mpirun -n _ ./ex1 -A_name matrix.dat -b_name vector.dat -n_name
>>> _null_space.dat -num_near_nullspace 6 -ksp_type cg -pc_type hypre
>>> -pc_hypre_boomeramg_strong_threshold 0.9 -ksp_view -log_view
>>> -log_view_memory -info :pc
>>>
>>> I am also attaching a standalone program to reproduce these options and
>>> the link to matrix, rhs and near null spaces (serial.tar 2.xz
>>> 
>>> ) if you would like to try as well. Please let me know if you have
>>> trouble accessing the link.
>>>
>>> Ashish
>>> --
>>> *From:* Mark Adams 
>>> *Sent:* Wednesday, April 17, 2024 7:52 PM
>>> *To:* Jeremy Theler (External) 
>>> *Cc:* Ashish Patel ; Scott McClennan <
>>> scott.mcclen...@ansys.com>
>>> *Subject:* Re: About recent changes in GAMG
>>>
>>>
>>> *[External Sender]*
>>>
>>>
>>> On Wed, Apr 17, 2024 at 7:20 AM Jeremy Theler (External) <
>>> jeremy.theler-...@ansys.com> wrote:
>>>
>>> Hey Mark. Long time no see! How are thing going over there?
>>>
>>> We are using PETSc main and have found a case where memory consumption
>>> explodes in parallel.
>>> Also, we see a non-negligible difference between
>>> PetscMemoryGetMaximumUsage() and PetscMallocGetMaximumUsage().
>>> Running in serial through /usr/bin/time, the max. resident set size
>>> matches the PetscMallocGetMaximumUsage() result.
>>> I would have expected it to match PetscMemoryGetMaximumUsage() instead.
>>>
>>>
>>> Yea, my interpretation of these methods is also that "Memory" should be
>>> >= "Malloc". But you are seeing the opposite.
>>>
>>> I don't have any idea what is going on with your big memory 

Re: [DISCUSS] Proposal for adding Telemetry via Scarf

[Jed Cunningham]

+1, looking forward to having better data!

Re: [VOTE] Release Airflow 2.9.0 from 2.9.0rc3

[Jed Cunningham]

+1 (binding)

Checked reproducibility, signatures, checksums, licences. Used it with the
helm chart with a few different configs.

Re: [VOTE] Release Airflow 2.9.0 from 2.9.0rc2

[Jed Cunningham]

+1 (binding)

Checked reproducibility, signatures, checksums, licences. Used it with the
helm chart with a few different configs. All looks good!

Re: [petsc-users] Correct way to set/track global numberings in DMPlex?

[Jed Brown]

 Matthew Knepley  writes: >> I'm developing routines that will read/write CGNS files to DMPlex and vice >> versa. >> One of the recurring challenges is the bookkeeping of global numbering for >>




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Matthew Knepley  writes:

>> I'm developing routines that will read/write CGNS files to DMPlex and vice
>> versa.
>> One of the recurring challenges is the bookkeeping of global numbering for
>> vertices and cells.
>> Currently, I am restricting my support to single Zone CGNS files, in which
>> the file provides global numbers for vertices and cells.
>>
>
> I thought Jed had put in parallel CGNS loading. If so, maybe you can
> transition to that. If not, we should get your stuff integrated.

We did implement this, but it's still in a branch. It's been on my plate for a while and I thought I would get to clean up that branch for merging this week, but that will have to wait for next week. (The current hang-up is mediating globally consistent edge orientation for isoperiodic meshes, as needed for cubic elements.)

How are you handling boundary conditions so far? Do you support periodicity?

[RESULT][VOTE] AIP-64: Keep TaskInstance try history

[Jed Cunningham]

Hello Airflow Community,

The vote for AIP-64 has completed and it has been accepted.

14 "+1" binding votes received:
- Jed Cunningham
- Tzu-ping Chung
- Pierra Jeambrun
- Kaxil Naik
- Jens Scheffler
- Jarek Potiuk
- Vikram Koka
- Amogh Desai
- Phani Kumar
- Niko Oliveira
- Brent Bovenzi
- Utkarsh Sharma
- Josh Fell
- Hussein Awala

6 "+1" non-binding received:
- Arita Basu
- Igor Kholopov
- Wei Lee
- Shubham Mehta
- Rahul Vats
- Ankit Chaurasia

Vote thread:
https://lists.apache.org/thread/cdrxd4tsq982gjmbbl32vp2ygt9dxgpk

Thanks everyone that took the time to vote!

Thanks,
Jed

Re: [petsc-users] using custom matrix vector multiplication

[Jed Brown]

 Interfaces like KSPSetOperators (https: //urldefense. us/v3/__https: //petsc. org/main/manualpages/KSP/KSPSetOperators/__;!!G_uCfscf7eWS!YINsVNEe8TcsVMY3AVwkS1hf46fWdiKi5JNOe9560N5QG1LPQyjMQgodivpJtg1IwxHgRR3_V3uHWG4h2AI$) have Amat and Pmat arguments. 




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Interfaces like KSPSetOperators (https://urldefense.us/v3/__https://petsc.org/main/manualpages/KSP/KSPSetOperators/__;!!G_uCfscf7eWS!YINsVNEe8TcsVMY3AVwkS1hf46fWdiKi5JNOe9560N5QG1LPQyjMQgodivpJtg1IwxHgRR3_V3uHWG4h2AI$) have Amat and Pmat arguments. The Amat is used as the Krylov operator and the Pmat is used for preconditioning.

In a general sense, Pmat is just whatever data is to be used by the preconditioner, though for algebraic preconditioners, it's usually regarded as an assembled matrix. If you're not using PCShell, then you need to think about what the preconditioner needs (conceptually or check the code).

Raju Mandhapati  writes:

> Hello,
>
> I want to use my own custom matrix vector multiplication routine (which
> will use finite difference method to calculate it). I will supply a matrix
> but that matrix should be used only for preconditioner and not for matrix
> vector multiplication. Is there a way to do it?
>
> thanks
> Raju.

[ANNOUNCE] Apache Airflow 2.8.4 Released

[Jed Cunningham]

Dear Airflow community,

I'm happy to announce that Airflow 2.8.4 was just released.

The released sources and packages can be downloaded via
https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-sources.html

Other installation methods are described in
https://airflow.apache.org/docs/apache-airflow/stable/installation/

We also made this version available on PyPI for convenience:
`pip install apache-airflow`
https://pypi.org/project/apache-airflow/2.8.4/

The documentation is available at:
https://airflow.apache.org/docs/apache-airflow/2.8.4/

Find the release notes here for more details:
https://airflow.apache.org/docs/apache-airflow/2.8.4/release_notes.html

Container images are published at:
https://hub.docker.com/r/apache/airflow/tags/?page=1=2.8.4

Thanks,
Jed

[ANNOUNCE] Apache Airflow 2.8.4 Released

[Jed Cunningham]

Dear Airflow community,

I'm happy to announce that Airflow 2.8.4 was just released.

The released sources and packages can be downloaded via
https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-sources.html

Other installation methods are described in
https://airflow.apache.org/docs/apache-airflow/stable/installation/

We also made this version available on PyPI for convenience:
`pip install apache-airflow`
https://pypi.org/project/apache-airflow/2.8.4/

The documentation is available at:
https://airflow.apache.org/docs/apache-airflow/2.8.4/

Find the release notes here for more details:
https://airflow.apache.org/docs/apache-airflow/2.8.4/release_notes.html

Container images are published at:
https://hub.docker.com/r/apache/airflow/tags/?page=1=2.8.4

Thanks,
Jed

[ANNOUNCE] Apache Airflow Helm Chart version 1.13.1 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.13.1  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.13.1/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.13.1/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.13.1/quick-start.html
️Release Notes:
https://airflow.apache.org/docs/helm-chart/1.13.1/release_notes.html

Thanks to all the contributors who made this possible.

Thanks,
Jed

[ANNOUNCE] Apache Airflow Helm Chart version 1.13.1 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.13.1  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.13.1/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.13.1/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.13.1/quick-start.html
️Release Notes:
https://airflow.apache.org/docs/helm-chart/1.13.1/release_notes.html

Thanks to all the contributors who made this possible.

Thanks,
Jed

[RESULT][VOTE] Release Airflow 2.8.4 from 2.8.4rc1

[Jed Cunningham]

Hello,

Apache Airflow 2.8.4 (based on RC1) has been accepted.

4 "+1" binding votes received:
- Jed Cunningham
- Jarek Potiuk
- Hussein Awala
- Andrey Anshin

3 "+1" non-binding votes received:

- Rahul Vats
- Amogh Desai
- Wei Lee

Vote thread:
https://lists.apache.org/thread/o7d198j2q5nxjm3osxz6mgglqgcof1jz

I'll continue with the release process, and the release announcement will
follow shortly.

Thanks,
Jed

Re: [VOTE] Release Airflow 2.8.4 from 2.8.4rc1

[Jed Cunningham]

Hey Andrey,

If you reimport from KEYS, I've already updated the expiration date a while
back :). But yes, that would be problematic otherwise.

Jed

On Sat, Mar 23, 2024 at 10:41 AM Andrey Anshin 
wrote:

> +1 binding
>
> Checked files, licences, signatures and also my changes.
>
> One small nit that I've found is that the key which is used for sign
> releases is expired, I'm not sure if it should be considered as a
> showstopper.
>
> ❯ gpg --verify apache_airflow-2.8.4-py3-none-any.whl.asc
> apache_airflow-2.8.4-py3-none-any.whl
> gpg: Signature made Wed Mar 20 19:17:26 2024 +04
> gpg:using RSA key E1A1E984F55B8F280BD9CBA20BB7163892A2E48E
> gpg:issuer "jedcunning...@apache.org"
> gpg: Good signature from "Jed Cunningham "
> [ultimate]
> gpg: Note: This key has expired!
> Primary key fingerprint: A020 DD36 34F1 A4D1 26A1  C554 7774 A4E5 90CB 0351
>  Subkey fingerprint: E1A1 E984 F55B 8F28 0BD9  CBA2 0BB7 1638 92A2 E48E
>
> ❯ gpg --list-options show-unusable-subkeys --list-keys
> A020DD3634F1A4D126A1C5547774A4E590CB0351
> pub   rsa4096 2022-01-05 [C]
>   A020DD3634F1A4D126A1C5547774A4E590CB0351
> uid   [ultimate] Jed Cunningham 
> sub   rsa4096 2022-01-05 [A] [expired: 2024-01-05]
> sub   rsa4096 2022-01-05 [E] [expired: 2024-01-05]
> sub   rsa4096 2022-01-05 [S] [expired: 2024-01-05]
>
>
>
>
> On Fri, 22 Mar 2024 at 15:24, Rahul Vats  wrote:
>
> > +1 (non-binding)
> >
> > Verified running our regression DAGS and API tests. LGTM
> >
> > Regards,
> > Rahul Vats
> > 9953794332
> >
> >
> > On Fri, 22 Mar 2024 at 15:24, Hussein Awala  wrote:
> >
> > > +1 (binding) checked licences, checksums, signatures, and source codes,
> > and
> > > ran some testing dags. All looks good.
> > >
> > > On Wed, Mar 20, 2024 at 7:54 PM Jarek Potiuk  wrote:
> > >
> > > > +1 (binding) - tested / verified all changes I was involved (either
> as
> > > > fixer, bug introducer or both, particularly when both), verified
> > > > reproducibility, licences, checksums, signatures, run a few DAGs -
> all
> > > > looks good.
> > > >
> > > > On Wed, Mar 20, 2024 at 4:56 PM Jed Cunningham <
> > jedcunning...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Hey fellow Airflowers,
> > > > >
> > > > > I have cut Airflow 2.8.4rc1. This email is calling a vote on the
> > > release,
> > > > > which will last at least 72 hours, from Wednesday, March 20, 2024
> at
> > > 4:00
> > > > > pm UTC
> > > > > until Saturday, March 23, 2024 at 4:00 pm UTC, and until 3 binding
> +1
> > > > votes
> > > > > have been received.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://www.timeanddate.com/worldclock/fixedtime.html/?msg=8=20240323T1600=1440
> > > > >
> > > > > Status of testing of the release is kept in
> > > > > https://github.com/apache/airflow/issues/38334
> > > > >
> > > > > Consider this my (binding) +1.
> > > > >
> > > > > Airflow 2.8.4rc1 is available at:
> > > > > https://dist.apache.org/repos/dist/dev/airflow/2.8.4rc1/
> > > > >
> > > > > *apache-airflow-2.8.4-source.tar.gz* is a source release that comes
> > > with
> > > > > INSTALL instructions.
> > > > > *apache-airflow-2.8.4.tar.gz* is the binary Python "sdist" release.
> > > > > *apache_airflow-2.8.4-py3-none-any.whl* is the binary Python wheel
> > > > "binary"
> > > > > release.
> > > > >
> > > > > Public keys are available at:
> > > > > https://dist.apache.org/repos/dist/release/airflow/KEYS
> > > > >
> > > > > Please vote accordingly:
> > > > >
> > > > > [ ] +1 approve
> > > > > [ ] +0 no opinion
> > > > > [ ] -1 disapprove with the reason
> > > > >
> > > > > Only votes from PMC members are binding, but all members of the
> > > community
> > > > > are encouraged to test the release and vote with "(non-binding)".
> > > > >
> > > > > The test procedure for PMC members is described in:
> > > > >
> > > > >
> > > >
> > >
> >
> https://gi

[RESULT][VOTE] Release Apache Airflow Helm Chart 1.13.1 based on 1.13.1rc1

[Jed Cunningham]

Hello all,

The vote to release Apache Airflow Helm Chart version 1.13.1 based on
1.13.1rc1 is now closed.

The vote PASSED with 3 binding "+1", 1 non-binding "+1" and 0 "-1" votes:

"+1" Binding votes:

  - Jed Cunningham
  - Jarek Potiuk
  - Hussein Awala

"+1" Non-Binding votes:

  - Amogh Desai

Vote thread:
https://lists.apache.org/thread/zsx1bv24c3mx362ctny4tvlrzjo25j7p

I'll continue with the release process and the release announcement will
follow shortly.

Thanks,
Jed

[VOTE] AIP-64: Keep TaskInstance try history

[Jed Cunningham]

Hello Airflow Community,

I would like to start a vote on AIP-64: Keep TaskInstance try history.

You can find the AIP here:
https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-64%3A+Keep+TaskInstance+try+history

Discussion Thread:
https://lists.apache.org/thread/vvm43tfchyo92hmf40fqvmq0f5845bjr

This is the first step in the AIP-63 DAG Versioning journey, though this
provides value in isolation as well:
https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-63%3A+DAG+Versioning

The vote will last until 2024-03-28 17:30 UTC and until at least 3 binding
votes have been cast.

Consider this my binding +1.

Please vote accordingly:

[ ] + 1 approve
[ ] + 0 no opinion
[ ] - 1 disapprove with the reason

Only votes from PMC members and committers are binding, but other members
of the community are encouraged to check the AIP and vote with
"(non-binding)".

Thanks,
Jed

Re: [petsc-users] Fortran interfaces: Google Summer of Code project?

[Jed Brown]

 Looks good to me. Thanks for taking the initiative. Martin Diehl  writes: > Dear All, > > pls. find attached the proposal for > https: //urldefense. us/v3/__https: //github. com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlg65QIRo$. 




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Looks good to me. Thanks for taking the initiative.

Martin Diehl  writes:

> Dear All,
>
> pls. find attached the proposal for
> https://urldefense.us/v3/__https://github.com/fortran-lang/webpage/wiki/GSoC-2024-Project-ideas__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlg65QIRo$.
>
> I tried to keep it general such that we keep all options open.
>
> Let me know if you want to change/add/remove anything and/or if you
> want to be listed as mentor.
>
> Since I've mixed up the deadline, the most urgent task is the finding
> of suitable candidates. Once it's online, I'll post on linkedin but
> ideally we can motivate someone who is already known.
>
> best regards,
> Martin
>
> On Thu, 2024-03-21 at 23:13 -0600, Jed Brown wrote:
>> Barry Smith  writes:
>> 
>> > > We already have the generated ftn-auto-interfaces/*.h90. The
>> > > INTERFACE keyword could be replaced with CONTAINS (making these
>> > > definitions instead of just interfaces), and then the bodies
>> > > could use iso_c_binding to call the C functions. That would
>> > > reduce repetition and be the standards-compliant way to do this.
>> > 
>> >    Sure, the interface and the stub go in the same file instead of
>> > two files. This is slightly nicer but not significantly simpler,
>> > and alone, it is not reason enough to write an entire new stub
>> > generator.
>> 
>> I agree, but if one *is* writing a new stub generator for good
>> reasons (like better automation/completeness), there's a case for
>> doing it this way unless users really need an environment in which
>> that feature can't be used.
>> 
>> > > What we do now with detecting the Fortran mangling scheme and
>> > > calling conventions "works" but doesn't conform to any standard
>> > > and there's nothing stopping Fortran implementations from
>> > > creating yet another variant that we have to deal with manually.
>> > 
>> >    From practical experience, calling C/Fortran using non-standards
>> > has only gotten easier over the last thirty-five years (fewer
>> > variants on how char* is handled); it has not gotten more
>> > complicated, so I submit the likelihood of "nothing stopping
>> > Fortran implementations from creating yet another variant that we
>> > have to deal with manually" is (though possible) rather unlikely.
>> > As far as I am concerned, much of iso_c_binding stuff just solved a
>> > problem that never really existed (except in some people's minds)
>> > since calling C/Fortran has always been easy, modulo knowing a tiny
>> > bit of information..
>> 
>> An examples for concreteness:
>> 
>> https://urldefense.us/v3/__https://fortranwiki.org/fortran/show/Generating*C*Interfaces__;Kys!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlsKy54Ps$
>> 
>> And discussion:
>> 
>> https://urldefense.us/v3/__https://fortran-lang.discourse.group/t/iso-c-binding-looking-for-practical-example-of-how-it-helps-with-mangling/3393/8__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTlVTiuUTk$
>> 
>> With this approach, one could even use method syntax like
>> ksp%SetOperators(J, Jpre), as in the nlopt-f project linked in the
>> top of this question. I don't know if we want that (it would be a
>> huge change for users, albeit it "easy"), but generating stubs in
>> Fortran using iso_c_binding opens a variety of possibilities for more
>> idiomatic bindings.
>
> -- 
> KU Leuven
> Department of Computer Science
> Department of Materials Engineering
> Celestijnenlaan 200a
> 3001 Leuven, Belgium
> # Improved generation of Fortran interfaces for [PETSc](https://urldefense.us/v3/__https://petsc.org__;!!G_uCfscf7eWS!blt-tme3gpPtGXW8o_NasIEtvlUql08d2_Q9Q83PvjPwLqIITWec4gsejnmPLpUCgMU8xuIEZgTljowbJv0$)
>
> PETSc, the Portable, Extensible Toolkit for Scientific Computation, pronounced PET-see, is for the scalable (parall

Re: [petsc-users] Fortran interfaces: Google Summer of Code project?

[Jed Brown]

 Barry Smith  writes: >> We already have the generated ftn-auto-interfaces/*. h90. The INTERFACE keyword could be replaced with CONTAINS (making these definitions instead of just interfaces), and then the bodies




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Barry Smith  writes:

>> We already have the generated ftn-auto-interfaces/*.h90. The INTERFACE keyword could be replaced with CONTAINS (making these definitions instead of just interfaces), and then the bodies could use iso_c_binding to call the C functions. That would reduce repetition and be the standards-compliant way to do this.
>
>Sure, the interface and the stub go in the same file instead of two files. This is slightly nicer but not significantly simpler, and alone, it is not reason enough to write an entire new stub generator.

I agree, but if one *is* writing a new stub generator for good reasons (like better automation/completeness), there's a case for doing it this way unless users really need an environment in which that feature can't be used.

>> What we do now with detecting the Fortran mangling scheme and calling conventions "works" but doesn't conform to any standard and there's nothing stopping Fortran implementations from creating yet another variant that we have to deal with manually.
>
>From practical experience, calling C/Fortran using non-standards has only gotten easier over the last thirty-five years (fewer variants on how char* is handled); it has not gotten more complicated, so I submit the likelihood of "nothing stopping Fortran implementations from creating yet another variant that we have to deal with manually" is (though possible) rather unlikely. As far as I am concerned, much of iso_c_binding stuff just solved a problem that never really existed (except in some people's minds) since calling C/Fortran has always been easy, modulo knowing a tiny bit of information..

An examples for concreteness:

https://urldefense.us/v3/__https://fortranwiki.org/fortran/show/Generating*C*Interfaces__;Kys!!G_uCfscf7eWS!YxEvDc1D4VU4lVeRBtAnpLnK6bOtF5usV8GsUXqiSsukaNrK5znZB16c7n5VUgIqFwNTGEkSEppdwFVuJSM$

And discussion:

https://urldefense.us/v3/__https://fortran-lang.discourse.group/t/iso-c-binding-looking-for-practical-example-of-how-it-helps-with-mangling/3393/8__;!!G_uCfscf7eWS!YxEvDc1D4VU4lVeRBtAnpLnK6bOtF5usV8GsUXqiSsukaNrK5znZB16c7n5VUgIqFwNTGEkSEppdx1pKPgQ$

With this approach, one could even use method syntax like ksp%SetOperators(J, Jpre), as in the nlopt-f project linked in the top of this question. I don't know if we want that (it would be a huge change for users, albeit it "easy"), but generating stubs in Fortran using iso_c_binding opens a variety of possibilities for more idiomatic bindings.

Re: [petsc-users] Fortran interfaces: Google Summer of Code project?

[Jed Brown]

 Barry Smith  writes: > In my limited understanding of the Fortran iso_c_binding, if we do not provide an equivalent Fortran stub (the user calls) that uses the iso_c_binding to call PETSc C code, then when the user




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Barry Smith  writes:

> In my limited understanding of the Fortran iso_c_binding, if we do not provide an equivalent Fortran stub (the user calls) that uses the iso_c_binding to call PETSc C code, then when the user calls PETSc C code directly via the iso_c_binding they have to pass iso_c_binding type arguments to the call. This I consider unacceptable. So my conclusion was there is the same number of stubs, just in a different language, so there is no reason to consider changing since we cannot "delete lots of stubs", but I could be wrong.

I don't want users to deal with iso_c_binding manually.

We already have the generated ftn-auto-interfaces/*.h90. The INTERFACE keyword could be replaced with CONTAINS (making these definitions instead of just interfaces), and then the bodies could use iso_c_binding to call the C functions. That would reduce repetition and be the standards-compliant way to do this. What we do now with detecting the Fortran mangling scheme and calling conventions "works" but doesn't conform to any standard and there's nothing stopping Fortran implementations from creating yet another variant that we have to deal with manually.

I don't know if this change would enable inlining without LTO, though I think the indirection through our C sourcef.c is rarely a performance factor for Fortran users.

Re: [petsc-users] Fortran interfaces: Google Summer of Code project?

[Jed Brown]

 Barry Smith  writes: > We've always had some tension between adding new features to bfort vs developing an entirely new tool (for example in Python (maybe calling a little LLVM to help parse the C function), for maybe




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




Barry Smith  writes:

>  We've always had some tension between adding new features to bfort vs developing an entirely new tool (for example in Python (maybe calling a little LLVM to help parse the C function), for maybe there is already a tool out there) to replace bfort.

Note that depending on LLVM (presumably libclang) is a nontrivial dependency if the users don't already have it installed on their systems. I'm all for making it easier to extend the stub generator, but an equally-hacky pybfort wouldn't make much difference. If some better tools have emerged or we have a clear idea for a better design, let's discuss that.

>  Both approaches have their advantages and disadvantages instead we've relied on the quick and dirty of providing the interfaces as needed). We have not needed the Fortran standard C interface stuff and I would prefer not to use it unless it offers some huge advantage).

Mainly that lots of C stubs could be deleted in favor of iso_c_binding.

[VOTE] Release Apache Airflow Helm Chart 1.13.1 based on 1.13.1rc1

[Jed Cunningham]

Hello Apache Airflow Community,

This is a call for the vote to release Helm Chart version 1.13.1.

The release candidate is available at:
https://dist.apache.org/repos/dist/dev/airflow/helm-chart/1.13.1rc1/

airflow-chart-1.13.1-source.tar.gz - is the "main source release" that
comes with INSTALL instructions.
airflow-1.13.1.tgz - is the binary Helm Chart release.

Public keys are available at: https://www.apache.org/dist/airflow/KEYS

For convenience "index.yaml" has been uploaded (though excluded from
voting), so you can also run the below commands.

helm repo add apache-airflow-dev
https://dist.apache.org/repos/dist/dev/airflow/helm-chart/1.13.1rc1/
helm repo update
helm install airflow apache-airflow-dev/airflow

airflow-1.13.1.tgz.prov - is also uploaded for verifying Chart Integrity,
though not strictly required for releasing the artifact based on ASF
Guidelines.

$ helm gpg verify airflow-1.13.1.tgz
gpg: Signature made Thu Mar 21 12:13:02 2024 MDT
gpg:using RSA key E1A1E984F55B8F280BD9CBA20BB7163892A2E48E
gpg:issuer "jedcunning...@apache.org"
gpg: Good signature from "Jed Cunningham "
[ultimate]
plugin: Chart SHA verified.
sha256:ed6b2dea0d8f99eb9bd9cd6bc418db95f88a7bb3b8d1afb7fdc266b1ea411a15

The vote will be open for at least 72 hours (2024-03-24 18:29 UTC) or until
the necessary number of votes is reached.

https://www.timeanddate.com/countdown/to?iso=20240324T1829=136=cursive

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but members of the community are
encouraged to test the release and vote with "(non-binding)".

Consider this my (binding) +1.

For license checks, the .rat-excludes files is included, so you can run the
following to verify licenses (just update your path to rat):

tar -xvf airflow-chart-1.13.1-source.tar.gz
cd airflow-chart-1.13.1
java -jar apache-rat-0.13.jar chart -E .rat-excludes

Please note that the version number excludes the `rcX` string, so it's now
simply 1.13.1. This will allow us to rename the artifact without modifying
the artifact checksums when we actually release it.

The status of testing the Helm Chart by the community is kept here:
https://github.com/apache/airflow/issues/38382

Thanks,
Jed

[VOTE] Release Airflow 2.8.4 from 2.8.4rc1

[Jed Cunningham]

Hey fellow Airflowers,

I have cut Airflow 2.8.4rc1. This email is calling a vote on the release,
which will last at least 72 hours, from Wednesday, March 20, 2024 at 4:00
pm UTC
until Saturday, March 23, 2024 at 4:00 pm UTC, and until 3 binding +1 votes
have been received.

https://www.timeanddate.com/worldclock/fixedtime.html/?msg=8=20240323T1600=1440

Status of testing of the release is kept in
https://github.com/apache/airflow/issues/38334

Consider this my (binding) +1.

Airflow 2.8.4rc1 is available at:
https://dist.apache.org/repos/dist/dev/airflow/2.8.4rc1/

*apache-airflow-2.8.4-source.tar.gz* is a source release that comes with
INSTALL instructions.
*apache-airflow-2.8.4.tar.gz* is the binary Python "sdist" release.
*apache_airflow-2.8.4-py3-none-any.whl* is the binary Python wheel "binary"
release.

Public keys are available at:
https://dist.apache.org/repos/dist/release/airflow/KEYS

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but all members of the community
are encouraged to test the release and vote with "(non-binding)".

The test procedure for PMC members is described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md#verify-the-release-candidate-by-pmc-members

The test procedure for and Contributors who would like to test this RC is
described in:
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_AIRFLOW.md#verify-the-release-candidate-by-contributors


Please note that the version number excludes the `rcX` string, so it's now
simply 2.8.4. This will allow us to rename the artifact without modifying
the artifact checksums when we actually release.

Release Notes:
https://github.com/apache/airflow/blob/2.8.4rc1/RELEASE_NOTES.rst

For information on what goes into a release please see:
https://github.com/apache/airflow/blob/main/dev/WHAT_GOES_INTO_THE_NEXT_RELEASE.md

Changes since 2.8.3:
*Bugs*:
- Fix incorrect serialization of ``FixedTimezone`` (#38139)
- Fix excessive permission changing for log task handler (#38164)
- Fix task instances list link (#38096)
- Fix a bug where scheduler heartrate parameter was not used (#37992)
- Add padding to prevent grid horizontal scroll overlapping tasks (#37942)
- Fix hash caching in ``ObjectStoragePath`` (#37769)

*Miscellaneous*:
- Limit importlib_resources as it breaks ``pytest_rewrites`` (#38095,
#38139)
- Limit ``pandas`` to ``<2.2`` (#37748)
- Bump ``croniter`` to fix an issue with 29 Feb cron expressions (#38198)

*Doc-only Change*:
- Tell users what to do if their scanners find issues in the image (#37652)
- Add a section about debugging in Docker Compose with PyCharm (#37940)
- Update deferrable docs to clarify kwargs when trigger resumes operator
(#38122)

Thanks,
Jed

Re: [VOTE] Remove experimental API

[Jed Cunningham]

I forgot to add the "why" - I view this as a breaking change still.

Re: [VOTE] Remove experimental API

[Jed Cunningham]

-1. Even though it's been deprecated for a really long time now, I don't
think we should remove it in a minor 2 release. I think we should wait
until the next major.

[Vo]:85 papers uploaded to LENR-CANR.org

[Jed Rothwell]

I uploaded 85 papers. The latest papers are shown here, but there are so
many this list is unhelpful:

https://lenr-canr.org/wordpress/?page_id=3009

I have appended another list below, which includes most of the new papers.


I uploaded 4 papers by W. B. Clarke. These cast doubt on results from
Arata, and Case. I recall that he and Mike McKubre did not get
along, although they co-authored some papers.

900. Clarke, W.B., *Search for 3He and 4He in Arata-Style Palladium
Cathodes I: A Negative Result.* Fusion Science and Technology, 2001. *40*
 ACC

http://lenr-canr.org/acrobat/ClarkeWBsearchforh.pdf
901. Clarke, W.B., *Search for 3He and 4He in Arata-Style Palladium
Cathodes II: Evidence for Tritium Production.* Fusion Science and
Technology, 2001 ACC

http://lenr-canr.org/acrobat/ClarkeWBsearchforha.pdf

903. Clarke, W.B., *Production of 4He in D2-Loaded Palladium-Carbon
Catalyst I.* Fusion Science and Technology, 2003. *43*(1): p. 122-127 ACC

http://lenr-canr.org/acrobat/ClarkeWBriproduction.pdf

904. Clarke, W.B., S.J. Bos, and B.M. Oliver, *Production of 4He in
D2-Loaded Palladium-Carbon Catalyst II.* Fusion Science and Technology,
2003. *43*(2): p. 250-255 ACC

http://lenr-canr.org/acrobat/ClarkeWBriproductiona.pdf

Clarke had some unkind things to say about Arata. So did Ed and I:

https://lenr-canr.org/acrobat/RothwellJreportonar.pdf

Arata was a genius. I think his palladium power approach was fruitful. It
was groundbreaking. But I think he was a little sloppy as an
experimentalist. I am no experimentalist at all, so I hesitate to say that.


Here are most of the papers I added today:

New to the database and newly uploaded

New: Ambadkar, A., electrolysis of d2o with a palladium cathode compared
with electrolysis of h2o with a platinum electrode: procedure and
experimental details
New: Bockris, J., do nuclear reactions take place under chemical simulation?
New: Bockris, J. O'M., speculative interpretation of overunity experiments
involving water electrolysis
New: Bush, B. F., data for 4he measurement
New: Bush, B. F., comments on "search for 3he and 4he in arata-style
palladium cathodes i: a negative result" and "search for 3he and 4he in
arata-style palladium cathodes ii: evidence for tritium production"
New: Cirillo, D., experimental evidence of a neutron flux generation in a
plasma discharge electrolytic cell
New: De Ninno, A., consequences of lattice expansive strain gradients on
hydrogen loading in palladium
New: Drebushchak, V. A., excess heat release during deuterium
sorption-desorption by finely powdered palladium deuteride
New: Dubinko, V. I., on the role of disorder in catalysis driven by
discrete breathers
New: Fralick, G. C., transmutations observed from pressure cycling
palladium silver metals with deuterium gas
New: Holmlid, L., heat generation above break-even from laser-induced
fusion in ultra-dense deuterium
New: Karabut, A., possible nuclear reactions mechanisms at glow discharge
in deuterium
New: McKubre, M. C. H., conditions for the observation of excess power in
the d/pd system
New: McKubre, M. C. H., electrochemistry and calorimetry in a packed-bed
flow-through electrochemical cell
New: Mizuno, T., excess heat evolution and analysis of elements for solid
state electrolyte in deuterium atmosphere during applied electric field
New: Stepanov. I. N., experimental measurement of excess thermal energy
released from a cell loaded with a mixture of nickel powder and lithium
aluminum hydride
New: Ohmori, T., enrichment of 41k isotope in potassium formed on and in a
rhenium electrode during plasma electrolysis in k2co3/h2o and k2co3/d2o
solutions
New: Srinivasan, M., excess heat and tritium measurements in ni-h2o
electrolytic cells
New: Vysotskii, V. I., the formation of correlated states and optimization
of the tunnel effect for low-energy particles under nonmonochromatic and
pulsed action on a potential barrier
New: Yamada, H., carbon production on palladium point electrode with
neutron burst under dc glow discharge in pressurized deuterium gas


Previously listed in database but not uploaded

On file: Adachi, G., (3)He and (4)He from D2 absorbed in LaNi5
On file: Alguero, M., An interpretation of some postelectrolysis nuclear
effects in deuterated titanium
On file: Asami, N., Material characteristics and behavior of highly
deuterated loaded palladium by electrolysis
On file: Battaglia, A., Neutron emission in Ni-H systems
On file: Belzner, A., Two fast mixed-conductor systems: deuterium and
hydrogen in palladium - thermal measurements and experimental considerations
On file: Bertalot, L., Study of deuterium charging in palladium by the
electrolysis of heavy water: heat excess production
On file: Bhadkamkar, A., Electron Charge Cluster Sparking in Aqueous
Solutions
On file: Bockris, J., Nuclear Transmutation: The reality of cold fusion
(Book Review)
On file: Bush, R. T., Electrolytically Simulated Cold Nuclear Synthesis of
Strontium from Rubidium
On file: Celani, F., Further 

Re: Zoom H1 essential recorder with voice guidance

[Jed Barton]

Let me know how to turn it on.  Thought about getting 1.

On Sat, Mar 9, 2024 at 2:52 PM Phil Halton  wrote:

> I saw this new recorder from Zoom in the 80 guys bulletin and so I picked
> one up and it just arrived. Unfortunately the manuals are crap. Although, I
> think I can suss out the various buttons and such. The problem is knowing
> how to operate the menu system. I think you first have to go in and
> activate The voice guidance, kinda like turning on voiceover for the first
> time. Is anybody else using this recorder? I’m not gonna send it back right
> away, I’ll mess around with it but I think I may have made a mistake
> purchase here. Please let me know if you’re using it.
> Sent from my IPhone
>
> --
> The following information is important for all members of the Mac
> Visionaries list.
>
> If you have any questions or concerns about the running of this list, or
> if you feel that a member's post is inappropriate, please contact the
> owners or moderators directly rather than posting on the list itself.
>
> Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark
> at:  mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at
> caraqu...@caraquinn.com
>
> The archives for this list can be searched at:
> http://www.mail-archive.com/macvisionaries@googlegroups.com/
> ---
> You received this message because you are subscribed to the Google Groups
> "MacVisionaries" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to macvisionaries+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/macvisionaries/A490B9C5-9D29-4E6B-A136-C01616DBCBA2%40gmail.com
> .
>

-- 
The following information is important for all members of the Mac Visionaries 
list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your Mac Visionaries list moderator is Mark Taylor.  You can reach mark at:  
mk...@ucla.edu and your owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/macvisionaries@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"MacVisionaries" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to macvisionaries+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/macvisionaries/CAOYEAep7GEwfqhyJZDSARXe-S%3D9YPcrH0himNYJ5sOKFcRc6xg%40mail.gmail.com.

[DISCUSS] AIP-63, AIP-64, and AIP-65: DAG Versioning

[Jed Cunningham]

Hello everyone!

I'm excited to start a discussion around DAG Versioning in Airflow. It's
been the most requested feature in the last 3 community surveys!

AIP-63: DAG Versioning
<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-63%3A+DAG+Versioning>

As this topic quickly becomes rather large, I've made AIP-63 an umbrella
AIP and split the specifics into separate AIPs:

AIP-64: Keep TaskInstance try history
<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-64%3A+Keep+TaskInstance+try+history>
AIP-65: Improve DAG history in UI
<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-65%3A+Improve+DAG+history+in+UI>
[WIP] AIP-66: Execution of specific DAG code versions
<https://cwiki.apache.org/confluence/display/AIRFLOW/%5BWIP%5D+AIP-66%3A+Execution+of+specific+DAG+versions>

AIP-64 and AIP-65 are ready to be discussed in depth, while AIP-66 is there
to provide an intentionally high level vision of what we may want to tackle
before Airflow's "DAG versioning" story is complete.

Thanks,
Jed

[ANNOUNCE] Apache Airflow Helm Chart version 1.13.0 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.13.0  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.13.0/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.13.0/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.13.0/quick-start.html
️   Release Notes:
https://airflow.apache.org/docs/helm-chart1.13.0/release_notes.html

Thanks to all the contributors who made this possible.

Thanks,
Jed

[ANNOUNCE] Apache Airflow Helm Chart version 1.13.0 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.13.0  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.13.0/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.13.0/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.13.0/quick-start.html
️   Release Notes:
https://airflow.apache.org/docs/helm-chart1.13.0/release_notes.html

Thanks to all the contributors who made this possible.

Thanks,
Jed

[RESULT][VOTE] Release Apache Airflow Helm Chart 1.13.0 based on 1.13.0rc1

[Jed Cunningham]

Hello all,

The vote to release Apache Airflow Helm Chart version 1.13.0 based on
1.13.0rc1 is now closed.

The vote PASSED with 3 binding "+1", 2 non-binding "+1" and 0 "-1" votes:

"+1" Binding votes:

  - Jed Cunningham
  - Jarek Potiuk
  - Ephraim Anierobi

"+1" Non-Binding votes:

  - Amogh Desai
  - Utkarsh Sharma

Vote thread:https://lists.apache.org/thread/0xgxsjwsbd8qk3h1tn4gj01hoplz1p5k

I'll continue with the release process and the release announcement
will follow shortly.

Thanks,
Jed

Re: [petsc-users] 'Preconditioning' with lower-order method

[Jed Brown]

 If you're having PETSc use coloring and have confirmed that the stencil is sufficient, then it would be nonsmoothness (again, consider the limiter you've chosen) preventing quadratic convergence (assuming that doesn't kick in eventually). Note




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




If you're having PETSc use coloring and have confirmed that the stencil is sufficient, then it would be nonsmoothness (again, consider the limiter you've chosen) preventing quadratic convergence (assuming that doesn't kick in eventually). Note that assembling a Jacobian of a second order TVD operator requires at least second neighbors while the first order needs only first neighbors, thus is much sparser and needs fewer colors to compute. I expect you're either not exploiting that in the timings or something else is amiss. You can run with `-log_view -snes_view -ksp_converged_reason` to get a bit more information about what's happening. 

"Zou, Ling via petsc-users"  writes:

> Barry, thank you.
> I am not sure if I exactly follow you on this:
> “Are you forming the Jacobian for the first and second order cases inside of Newton?”
>
> The problem that we deal with, heat/mass transfer in heterogeneous systems (reactor system), is generally small in terms of size, i.e., # of DOFs (several k to maybe 100k level), so for now, I completely rely on PETSc to compute Jacobian, i.e., finite-differencing.
>
> That’s a good suggestion to see the time spent during various events.
> What motivated me to try the options are the following observations.
>
> 2nd order FVM:
>
> Time Step 149, time = 13229.7, dt = 100
>
> NL Step =  0, fnorm =  7.80968E-03
>
> NL Step =  1, fnorm =  7.65731E-03
>
> NL Step =  2, fnorm =  6.85034E-03
>
> NL Step =  3, fnorm =  6.11873E-03
>
> NL Step =  4, fnorm =  1.57347E-03
>
> NL Step =  5, fnorm =  9.03536E-04
>
>  Solve Converged!
>
> 1st order FVM:
>
> Time Step 149, time = 13229.7, dt = 100
>
> NL Step =  0, fnorm =  7.90072E-03
>
> NL Step =  1, fnorm =  2.01919E-04
>
> NL Step =  2, fnorm =  1.06960E-05
>
> NL Step =  3, fnorm =  2.41683E-09
>
>  Solve Converged!
>
> Notice the obvious ‘stagnant’ in residual for the 2nd order method while not in the 1st order.
> For the same problem, the wall time is 10 sec vs 6 sec. I would be happy if I can reduce 2 sec for the 2nd order method.
>
> -Ling
>
> From: Barry Smith 
> Date: Sunday, March 3, 2024 at 12:06 PM
> To: Zou, Ling 
> Cc: petsc-users@mcs.anl.gov 
> Subject: Re: [petsc-users] 'Preconditioning' with lower-order method
> Are you forming the Jacobian for the first and second order cases inside of Newton? You can run both with -log_view to see how much time is spent in the various events (compute function, compute Jacobian, linear solve, .. . ) for the two cases
> ZjQcmQRYFpfptBannerStart
> This Message Is From an External Sender
> This message came from outside your organization.
>
> ZjQcmQRYFpfptBannerEnd
>
>Are you forming the Jacobian for the first and second order cases inside of Newton?
>
>You can run both with -log_view to see how much time is spent in the various events (compute function, compute Jacobian, linear solve, ...) for the two cases and compare them.
>
>
>
>
> On Mar 3, 2024, at 11:42 AM, Zou, Ling via petsc-users  wrote:
>
> Original email may have been sent to the incorrect place.
> See below.
>
> -Ling
>
> From: Zou, Ling >
> Date: Sunday, March 3, 2024 at 10:34 AM
> To: petsc-users >
> Subject: 'Preconditioning' with lower-order method
> Hi all,
>
> I am solving a PDE system over a spatial domain. Numerical methods are:
>
>   *   Finite volume method (both 1st and 2nd order implemented)
>   *   BDF1 and BDF2 for time integration.
> What I have noticed is that 1st order FVM converges much faster than 2nd order FVM, regardless the time integration scheme. Well, not surprising since 2nd order FVM introduces additional non-linearity.
>
> I’m thinking about two possible ways to speed up 2nd order FVM, and would like to get some thoughts or community knowledge before jumping into code implementation.
>
> Say, let the 2nd order FVM residual function be F2(x) = 0; and the 1st order FVM residual function be F1(x) = 0.
>
>   1.  Option – 1, multi-step for each time step
> Step 1: solving F1(x) = 0 to obtain a temporary solution x1
> Step 2: feed x1 as an initial guess to solve F2(x) = 0 to obtain the final solution.
> [Not sure if gain any saving at all]
>
>
>   1.  Option -2, dynamically changing residual function F(x)
> In pseudo code, would be something like.
>
> snesFormFunction(SNES snes, Vec u, Vec f, void *)
> {
>   if (snes.nl_it_no < 4) // 4 being arbitrary here
> f = F1(u);
>   else
> f = F2(u);
> }
>
> I know this might be a bit crazy since it may crash after switching residual function, still, any thoughts?
>

Re: [petsc-users] FW: 'Preconditioning' with lower-order method

[Jed Brown]

 One option is to form the preconditioner using the FV1 method, which is sparser and satisfies h-ellipticity, while using FV2 for the residual and (optionally) for matrix-free operator application. FV1 is a highly diffusive method so in a sense,




ZjQcmQRYFpfptBannerStart




  

  
	This Message Is From an External Sender
  
  
This message came from outside your organization.
  



 
  


ZjQcmQRYFpfptBannerEnd




One option is to form the preconditioner using the FV1 method, which is sparser and satisfies h-ellipticity, while using FV2 for the residual and (optionally) for matrix-free operator application.

FV1 is a highly diffusive method so in a sense, it's much less faithful to the physics and (say, in the case of fluids) similar to a much lower-Reynolds number (if you use a modified equation analysis to work out the effective Reynolds number in the presence of the numerical diffusion).

It's good to put some thought into your choice of limiter. Note that intersection of second order and TVD methods leads to mandatory nonsmoothness (discontinuous derivatives). 

"Zou, Ling via petsc-users"  writes:

> Original email may have been sent to the incorrect place.
> See below.
>
> -Ling
>
> From: Zou, Ling 
> Date: Sunday, March 3, 2024 at 10:34 AM
> To: petsc-users 
> Subject: 'Preconditioning' with lower-order method
> Hi all,
>
> I am solving a PDE system over a spatial domain. Numerical methods are:
>
>   *   Finite volume method (both 1st and 2nd order implemented)
>   *   BDF1 and BDF2 for time integration.
> What I have noticed is that 1st order FVM converges much faster than 2nd order FVM, regardless the time integration scheme. Well, not surprising since 2nd order FVM introduces additional non-linearity.
>
> I’m thinking about two possible ways to speed up 2nd order FVM, and would like to get some thoughts or community knowledge before jumping into code implementation.
>
> Say, let the 2nd order FVM residual function be F2(x) = 0; and the 1st order FVM residual function be F1(x) = 0.
>
>   1.  Option – 1, multi-step for each time step
> Step 1: solving F1(x) = 0 to obtain a temporary solution x1
> Step 2: feed x1 as an initial guess to solve F2(x) = 0 to obtain the final solution.
> [Not sure if gain any saving at all]
>
>
>   1.  Option -2, dynamically changing residual function F(x)
>
> In pseudo code, would be something like.
>
>
>
> snesFormFunction(SNES snes, Vec u, Vec f, void *)
>
> {
>
>   if (snes.nl_it_no < 4) // 4 being arbitrary here
>
> f = F1(u);
>
>   else
>
> f = F2(u);
>
> }
>
>
>
> I know this might be a bit crazy since it may crash after switching residual function, still, any thoughts?
>
> Best,
>
> -Ling

[VOTE] Release Apache Airflow Helm Chart 1.13.0 based on 1.13.0rc1

[Jed Cunningham]

Hello Apache Airflow Community,

This is a call for the vote to release Helm Chart version 1.13.0.

The release candidate is available at:
https://dist.apache.org/repos/dist/dev/airflow/helm-chart/1.13.0rc1/

airflow-chart-1.13.0-source.tar.gz - is the "main source release" that
comes with INSTALL instructions.
airflow-1.13.0.tgz - is the binary Helm Chart release.

Public keys are available at: https://www.apache.org/dist/airflow/KEYS

For convenience "index.yaml" has been uploaded (though excluded from
voting), so you can also run the below commands.

helm repo add apache-airflow-dev
https://dist.apache.org/repos/dist/dev/airflow/helm-chart/1.13.0rc1/
helm repo update
helm install airflow apache-airflow-dev/airflow

airflow-1.13.0.tgz.prov - is also uploaded for verifying Chart Integrity,
though not strictly required for releasing the artifact based on ASF
Guidelines.

$ helm gpg verify airflow-1.13.0.tgz
gpg: Signature made Fri Mar  1 21:16:51 2024 MST
gpg:using RSA key E1A1E984F55B8F280BD9CBA20BB7163892A2E48E
gpg:issuer "jedcunning...@apache.org"
gpg: Good signature from "Jed Cunningham "
[ultimate]
plugin: Chart SHA verified.
sha256:23155cf90b66c8ec6d49d2060686f90d23329eecf71c5368b1f0b06681b816cc

The vote will be open for at least 72 hours (2024-03-05 04:35 UTC) or until
the necessary number of votes is reached.

https://www.timeanddate.com/countdown/to?iso=20240305T0435=136=cursive

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but members of the community are
encouraged to test the release and vote with "(non-binding)".

Consider this my (binding) +1.

For license checks, the .rat-excludes files is included, so you can run the
following to verify licenses (just update your path to rat):

tar -xvf airflow-chart-1.13.0-source.tar.gz
cd airflow-chart-1.13.0
java -jar apache-rat-0.13.jar chart -E .rat-excludes

Please note that the version number excludes the `rcX` string, so it's now
simply 1.13.0. This will allow us to rename the artifact without modifying
the artifact checksums when we actually release it.

The status of testing the Helm Chart by the community is kept here:
https://github.com/apache/airflow/issues/37844

Thanks,
Jed

Re: [VOTE] January 2024 PR of the Month

[Jed Cunningham]

I'm down for #37101 too, but we might consider including #37016
 as well. The former is just
a simpler interface for the latter.

Re: [Vo]:OT: AI generated video is progressing rapidly

[Jed Rothwell]

I asked the Bot about F's original paper:
https://lenr-canr.org/acrobat/Fleischmanelectroche.pdf

My questions were mainly about these two paragraphs:

(a) Excess enthalpy generation is markedly dependent on the applied current
density (i.e. magnitude of the shift in
the chemical potential) and is proportional to the volume of the
electrodes, i.e. we are dealing with a phenomenon in
the bulk of the Pd electrodes.

(b) Enthalpy generation can exceed 10 W cm-3 of the palladium electrode;
this is maintained for experiment times
in excess of 120 h, during which typically heat in excess of 4 MJ cm-3 of
electrode volume was liberated. It is
inconceivable that this could be due to anything but nuclear processes.

*Overview* (auto-generated)
The document is about a study on electrochemically induced nuclear fusion
of deuterium.

*What is the H/D separation factor for absorbed hydrogen and
deuterium?* (auto-generated
question)
The document mentions that the H/D separation factor for absorbed hydrogen
and deuterium is of special interest and is explained in Figures 4 and 6 of
reference 2. However, the specific value of the H/D separation factor is
not provided in the document.


[The following are my questions, not auto-generated]
*What is the energy density of the reaction?*
The document does not explicitly state the energy density of the reaction.


*Is the reaction in proportion to surface area or volume?*
Based on the information provided in the document, it is not explicitly
stated whether the reaction is in proportion to surface area or volume.
However, we can make some inferences based on the data provided in Table 1.

Table 1 shows the generation of excess enthalpy in Pd cathodes as a
function of current density and electrode size. The "Excess specific rate
of heating" column provides the rate of excess heating per unit volume (W
cm-3).

>From the data in Table 1, we can observe that the "Excess specific rate of
heating" increases with increasing electrode size (dimensions) and current
density. This suggests that the reaction is likely dependent on the volume
of the electrode rather than just the surface area.

Additionally, the document mentions that the effects of enthalpy generation
are proportional to the volume of the electrodes and that the experiments
are close to the break-even point. This further supports the idea that the
reaction is dependent on the volume of the electrode.

Therefore, based on the information provided, it can be inferred that the
reaction is likely in proportion to the volume of the electrode.


*Could the enthalpy generation be caused by a chemical process?*

No, the enthalpy generation observed in the experiments is not likely to be
caused by a chemical process. The document mentions that the magnitude of
the effects observed in the experiments is too large to be explained by
anything other than nuclear processes. The excess enthalpy generation is
proportional to the volume of the electrodes and can exceed 10 W cm-3 of
the palladium electrode. This level of enthalpy release is inconceivable to
be due to a chemical process. Additionally, the document states that the
effects observed in the experiments are consistent with nuclear processes
and that reactions (v) and (vi) (2D + 2D fusion reactions) are only a small
part of the overall reaction scheme. Therefore, it is highly unlikely that
the enthalpy generation is caused by a chemical process.

Re: [Vo]:OT: AI generated video is progressing rapidly

[Jed Rothwell]

Document processing AI is also making progress. Adobe Acrobat just added a
new feature, the AI Assistant. It works with documents in native Acrobat
format, not a scanned document converted to Acrobat. I tried it with my
book, but it said, "the feature only supports files with less than 120
pages." So I tried it with my paper, "How to Fix Global Warming."
https://lenr-canr.org/acrobat/RothwellJhowtofixgl.pdf

Here are some of the responses from the AI:


*Overview* (generates automatically when you turn on the AI)

The document discusses how cold fusion technology can help mitigate global
warming by eliminating carbon emissions and enhancing carbon sequestration
through reforestation projects.


*Provide a list of the 5 most important points* (one of the many
auto-generated questions that the AI suggests)

   1. Cold fusion does not produce carbon dioxide, so if it replaces other
   sources of energy, carbon emissions would stop. [1]
   2. Cold fusion can enhance the removal of carbon from the atmosphere by
   reforestation. [2] It can increase the amount of carbon captured by a
   factor of ten and reduce the cost of the project significantly.
   3. Cold fusion technology can be used to stop the natural boom and bust
   cycle of forest carbon by burying charcoal made from deadwood underground,
   speeding up the formation of coal.
   4. Cold fusion devices do not produce dangerous radiation and can safely
   contain tritium.

[The footnotes in square brackets jump to the place in the document where
this assertion appears.]


*What are the two technologies used to expand forests in the carbon
sequestration project?* (Another auto-generated question)

The two technologies used to expand forests in the carbon sequestration
project are indoor farms and "cultured meat" grown from animal cells.


*What is the power density by volume of a cold fusion cathode?* (Auto
generated question)
The power density by volume of a cold fusion cathode is 300 W/cm3. This
information can be found in Table 1 of the document, which compares the
power density of cold fusion cathodes from the best experiments to fission
reactor fuel pellets. The table states that the volume of a cold fusion
cathode is 0.3 cm3 and its power density by volume is 300 W/cm3.


*What did the author in the New York Times have to say about forest
sequestation [spelled wrong!]?* (My question. I deliberately did not name
the author. But I spelled sequestration wrong by accident.)

The author in the New York Times wrote an op-ed titled "Let’s Not Pretend
Planting Trees Is a Permanent Climate Solution." The author argues that
while trees can remove carbon dioxide from the atmosphere, relying solely
on tree planting to offset emissions is not a permanent solution. The
author suggests that using trees to offset emissions can be seen as hitting
the "climate snooze button," as the carbon in trees eventually returns to
the atmosphere through forest fires or decomposition. The author emphasizes
the need for more permanent solutions to address climate change.


[Correct]


*What was the name of that author?* (My question. Too ambiguous)

The name of the author mentioned in the document is Jed Rothwell.


*What was the name of the author of the New York Times article?* (My
question.)

The name of the author of the New York Times article is not mentioned in
the document.


[The author is listed in footnote 9. I guess it is asking too much for the
AI to go from the text describing "Let's Not Pretend . . ." to the footnote
listing the author name.]


[This works much better than the AI that I installed at LENR-CANR.org.
Which, alas, I removed. I suppose it works better because: 1. It is only
running on one document; 2. Adobe tweaked the AI bot to work well with
academic documents, with abstracts, tables and whatnot. In one response it
said: "Please double-check my response carefully. Like many AI models, I'm
still learning how to understand tables in documents."]

[ANNOUNCE] Apache Airflow Helm Chart version 1.12.0 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.12.0  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.12.0/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.12.0/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.12.0/quick-start.html
️   Release Notes:
https://airflow.apache.org/docs/helm-chart/1.12.0/release_notes.html

Thanks to all the contributors who made this possible.

Thanks,
Jed

[ANNOUNCE] Apache Airflow Helm Chart version 1.12.0 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.12.0  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.12.0/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.12.0/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.12.0/quick-start.html
️   Release Notes:
https://airflow.apache.org/docs/helm-chart/1.12.0/release_notes.html

Thanks to all the contributors who made this possible.

Thanks,
Jed

[RESULT][VOTE] Release Apache Airflow Helm Chart 1.12.0 based on 1.12.0rc1

[Jed Cunningham]

Hello all,

The vote to release Apache Airflow Helm Chart version 1.12.0 based on
1.12.0rc1 is now closed.

The vote PASSED with 3 binding "+1" votes:

"+1" Binding votes:

  - Jed Cunningham
  - Jarek Potiuk
  - Hussein Awala

Vote thread:
https://lists.apache.org/thread/pqz480pfy5klbvxbf46s4thgjyooz1h9

I'll continue with the release process and the release announcement will
follow shortly.

Thanks,
Jed

[VOTE] Release Apache Airflow Helm Chart 1.12.0 based on 1.12.0rc1

[Jed Cunningham]

Hello Apache Airflow Community,

This is a call for the vote to release Helm Chart version 1.12.0.

The release candidate is available at:
https://dist.apache.org/repos/dist/dev/airflow/helm-chart/1.12.0rc1/

airflow-chart-1.12.0-source.tar.gz - is the "main source release" that
comes with INSTALL instructions.
airflow-1.12.0.tgz - is the binary Helm Chart release.

Public keys are available at: https://www.apache.org/dist/airflow/KEYS

For convenience "index.yaml" has been uploaded (though excluded from
voting), so you can also run the below commands.

helm repo add apache-airflow-dev
https://dist.apache.org/repos/dist/dev/airflow/helm-chart/1.12.0rc1/
helm repo update
helm install airflow apache-airflow-dev/airflow

airflow-1.12.0.tgz.prov - is also uploaded for verifying Chart Integrity,
though not strictly required for releasing the artifact based on ASF
Guidelines.

$ helm gpg verify airflow-1.12.0.tgz
gpg: Signature made Thu Feb  8 12:21:08 2024 MST
gpg:using RSA key E1A1E984F55B8F280BD9CBA20BB7163892A2E48E
gpg:issuer "jedcunning...@apache.org"
gpg: Good signature from "Jed Cunningham "
[ultimate]
plugin: Chart SHA verified.
sha256:a261081a40cb88c9052ad9c90968ddb701a2205d0eae816e7945a5b15466f054

The vote will be open for at least 72 hours (2024-02-11 19:45 UTC) or until
the necessary number of votes is reached.

https://www.timeanddate.com/countdown/to?iso=20240211T1945=136=cursive

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason

Only votes from PMC members are binding, but members of the community are
encouraged to test the release and vote with "(non-binding)".

Consider this my (binding) +1.

For license checks, the .rat-excludes files is included, so you can run the
following to verify licenses (just update your path to rat):

tar -xvf airflow-chart-1.12.0-source.tar.gz
cd airflow-chart-1.12.0
java -jar apache-rat-0.13.jar chart -E .rat-excludes

Please note that the version number excludes the `rcX` string, so it's now
simply 1.12.0. This will allow us to rename the artifact without modifying
the artifact checksums when we actually release it.

The status of testing the Helm Chart by the community is kept here:
https://github.com/apache/airflow/issues/37259

Thanks,
Jed

Re: [DISCUSS] Rename channels on slack

[Jed Cunningham]

That's not what I'm proposing. I should have been more verbose before,
sorry. Let me rephrase.

Don't rename #development. Leave it where it is, restrict posting to admins
only. Create a new, fresh #contributing where everyone is still welcome.
One of us admins will post in #development with links to #troubleshooting,
#random, #contributing, etc. But #development is "dead" at that point for
everyone, just sticking around for a while so folks have time to
navigate/join the channels they care about going forward.

Basically, don't just rename #development -> #contributing, and carry 14k
folks along with us. But leave a map in #development for folks.

Re: [DISCUSS] Rename channels on slack

[Jed Cunningham]

Sounds good to me. We already have much more niche channels than best
practices would be. Worst case no one uses it and we can purge it down the
road, no harm no foul.

One thing we should consider is not renaming development, but starting with
a fresh channel for contributing. There are nearly 14k people in
development today. Maybe we restrict who can post in development for a
period of time with a message directing folks to the right places?

Re: [VOTE] "Require conversation resolution" setting in PRs as permanent solution

[Jed Cunningham]

-0.5

Re: [Vo]:Nissan Leaf

[Jed Rothwell]

Robin  wrote:

Does anyone know if the original version of the Nissan Leaf, released in
> 2010, had bi-directional charging capability?
>

I do not think so.

I had an older Leaf, which I gave to my daughter. I do not recall anything
like that.

Re: [petsc-users] Parallel vector layout for TAO optimization with separable state/design structure

[Jed Brown]

For a bit of assistance, you can use DMComposite and DMRedundantCreate; see 
src/snes/tutorials/ex21.c and ex22.c.

Note that when computing redundantly, it's critical that the computation be 
deterministic (i.e., not using atomics or randomness without matching seeds) so 
the logic stays collective.

This merge request may also be relevant and comments related to your needs 
would be welcome in the discussion. 

https://gitlab.com/petsc/petsc/-/merge_requests/6531

Barry Smith  writes:

>This is a problem with MPI programming and optimization; I am unaware of a 
> perfect solution.
>
>Put the design variables into the solution vector on MPI rank 0, and when 
> doing your objective/gradient, send the values to all the MPI processes where 
> you use them. You can use a VecScatter to handle the communication you need 
> or MPI_Scatter() etc whatever makes the most sense in your code. 
>
>Barry
>
>
>> On Jan 30, 2024, at 10:53 AM, Guenther, Stefanie via petsc-users 
>>  wrote:
>> 
>> Hi Petsc team, 
>>  
>> I have a question regarding parallel layout of a Petsc vector to be used in 
>> TAO optimizers for cases where the optimization variables split into 
>> ‘design’ and ‘state’ variables (e.g. such as in PDE-constrained optimization 
>> as in tao_lcl). In our case, the state variable naturally parallelizes 
>> evenly amongst multiple processors and this distribution is fixed. The 
>> ‘design’ vector however does not, it is very short compared to the state 
>> vector and it is required on all state-processors when evaluating the 
>> objective function and gradient. My question would be how the TAO 
>> optimization vector x = [design,state] should be created in such a way that 
>> the ‘state’ part is distributed as needed in our solver, while the design 
>> part is not.
>>  
>> My only idea so far was to copy the design variables to all processors and 
>> augment / interleave the optimization vector as x = [state_proc1,design, 
>> state_proc2, design, … ] . When creating this vector in parallel on 
>> PETSC_COMM_WORLD, each processor would then own the same number of variables 
>> ( [state_proc, design] ), as long as the numbers match up, and I would 
>> only need to be careful when gathering the gradient wrt the design parts 
>> from all processors.
>>  
>> This seems cumbersome however, and I would be worried whether the 
>> optimization problem is harder to solve this way. Is there any other way to 
>> achieve this splitting, that I am missing here? Note that the distribution 
>> of the state itself is given and can not be changed, and that the state vs 
>> design vectors have very different (and independent) dimensions.
>>  
>> Thanks for your help and thoughts!
>> Best,
>> Stefanie

Re: [VOTE] Airflow Providers prepared on January 22, 2024

[Jed Cunningham]

+1 (binding) checked binary reproduction, licences, signatures, and
checksums.

On my system the binary reproduction check for the source tarball did fail,
but I spot verified the tarball contents are correct. I'm still
investigating, but no reason to hold the release for this.

Re: [VOTE] Release Airflow 2.8.1 from 2.8.1rc1

[Jed Cunningham]

+1 (binding)

Checked signatures, checksums, licences. Used it with the helm chart with a
few different configs

[Vo]:New paper from B-J. Huang et al.

[Jed Rothwell]

Huang, B.-J., et al., *Water can trigger nuclear reaction to produce energy
and isotope gases.* Scientific Reports, 2024. *14*(1): p. 214.

https://www.nature.com/articles/s41598-023-50824-8.epdf

[krunner] [Bug 469183] Krunner results order is unintuitive and often deprioritize the obvious choice

[Jed]

https://bugs.kde.org/show_bug.cgi?id=469183

Jed  changed:

   What|Removed |Added

 CC||kdeb...@jedfonner.com

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Jed Brown]

Then just use MatShell. I see the docs need some work to clarify this, but 
MatCreateSNESMF is to specify matrix-free finite differencing from code 
(perhaps where one wants to customize parameters).

Yi Hu  writes:

> Dear Jed,
>
> Thanks for your reply. I have an analytical one to implement.
>
> Best, Yi
>
> -Original Message-
> From: Jed Brown  
> Sent: Wednesday, December 20, 2023 5:40 PM
> To: Yi Hu ; petsc-users@mcs.anl.gov
> Subject: Re: [petsc-users] fortran interface to snes matrix-free jacobian
>
> Are you wanting an analytic matrix-free operator or one created for you based 
> on finite differencing? If the latter, just use -snes_mf or -snes_mf_operator.
>
> https://petsc.org/release/manual/snes/#jacobian-evaluation
>
> Yi Hu  writes:
>
>> Dear PETSc team,
>>  
>> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
>> saw the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). 
>> I am wondering if you have the fortran equivalence?
>>  
>> I think for my problem in the main program I need to do 
>> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). 
>> Then in myJacobian() subroutine I have to create the operator from 
>> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
>> MatShellSetOperation(). Am I correct? 
>>  
>> Are these fortran subroutines available? I saw an example in ts module 
>> as ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
>> would like to use ngmres, I then need to stay in the SNES.
>>  
>> Thanks for your help.
>>  
>> Best wishes,
>> Yi
>>
>> -
>> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>>
>> Max-Planck-Institut für Eisenforschung GmbH Max-Planck-Straße 1
>> D-40237 Düsseldorf
>>  
>> Handelsregister B 2533
>> Amtsgericht Düsseldorf
>>  
>> Geschäftsführung
>> Prof. Dr. Gerhard Dehm
>> Prof. Dr. Jörg Neugebauer
>> Prof. Dr. Dierk Raabe
>> Dr. Kai de Weldige
>>  
>> Ust.-Id.-Nr.: DE 11 93 58 514
>> Steuernummer: 105 5891 1000
>>
>>
>> Please consider that invitations and e-mails of our institute are only 
>> valid if they end with …@mpie.de.
>> If you are not sure of the validity please contact r...@mpie.de
>>
>> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails 
>> aus unserem Haus nur mit der Endung …@mpie.de gültig sind.
>> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
>> -
>
>
> -
> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße 1
> D-40237 Düsseldorf
>  
> Handelsregister B 2533 
> Amtsgericht Düsseldorf
>  
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>  
> Ust.-Id.-Nr.: DE 11 93 58 514 
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are 
> only valid if they end with …@mpie.de. 
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -

Re: [petsc-users] fortran interface to snes matrix-free jacobian

[Jed Brown]

Are you wanting an analytic matrix-free operator or one created for you based 
on finite differencing? If the latter, just use -snes_mf or -snes_mf_operator.

https://petsc.org/release/manual/snes/#jacobian-evaluation

Yi Hu  writes:

> Dear PETSc team,
>  
> My  solution scheme relies on a matrix-free jacobian in the SNES solver. I 
> saw the useful C interface like MatCreateSNESMF(), DMSNESCreateJacobianMF(). 
> I am wondering if you have the fortran equivalence?
>  
> I think for my problem in the main program I need to do 
> DMDASNESsetJacobianLocal(DM, INSERT_VALUES, myJacobian, ctx, err_petsc). Then 
> in myJacobian() subroutine I have to create the operator from 
> DMSNESCreateJacobianMF(), and register my own MATOP_MULT from 
> MatShellSetOperation(). Am I correct? 
>  
> Are these fortran subroutines available? I saw an example in ts module as 
> ex22f_mf.F90 which behaves similar as what I would like to do. Because I 
> would like to use ngmres, I then need to stay in the SNES.  
>  
> Thanks for your help.
>  
> Best wishes,
> Yi
>
> -
> Stay up to date and follow us on LinkedIn, Twitter and YouTube.
>
> Max-Planck-Institut für Eisenforschung GmbH
> Max-Planck-Straße 1
> D-40237 Düsseldorf
>  
> Handelsregister B 2533 
> Amtsgericht Düsseldorf
>  
> Geschäftsführung
> Prof. Dr. Gerhard Dehm
> Prof. Dr. Jörg Neugebauer
> Prof. Dr. Dierk Raabe
> Dr. Kai de Weldige
>  
> Ust.-Id.-Nr.: DE 11 93 58 514 
> Steuernummer: 105 5891 1000
>
>
> Please consider that invitations and e-mails of our institute are 
> only valid if they end with …@mpie.de. 
> If you are not sure of the validity please contact r...@mpie.de
>
> Bitte beachten Sie, dass Einladungen zu Veranstaltungen und E-Mails
> aus unserem Haus nur mit der Endung …@mpie.de gültig sind. 
> In Zweifelsfällen wenden Sie sich bitte an r...@mpie.de
> -

Re: [petsc-users] [EXTERNAL] Re: Call to DMSetMatrixPreallocateSkip not changing allocation behavior

[Jed Brown]

Great, thanks for letting us know. It'll merge to release shortly and thus be 
in petsc >= 3.20.3.

"Fackler, Philip"  writes:

> Jed,
>
> That seems to have worked (ridiculously well). It's now 55MB, and it's 
> happening in the call to MatSetPreallocationCOO.
>
> Thank you,
>
> Philip Fackler
> Research Software Engineer, Application Engineering Group
> Advanced Computing Systems Research Section
> Computer Science and Mathematics Division
> Oak Ridge National Laboratory
> 
> From: Jed Brown 
> Sent: Thursday, December 14, 2023 16:27
> To: Fackler, Philip ; petsc-users@mcs.anl.gov 
> ; xolotl-psi-developm...@lists.sourceforge.net 
> 
> Subject: [EXTERNAL] Re: [petsc-users] Call to DMSetMatrixPreallocateSkip not 
> changing allocation behavior
>
> I had a one-character typo in the diff above. This MR to release should work 
> now.
>
> https://urldefense.us/v2/url?u=https-3A__gitlab.com_petsc_petsc_-2D_merge-5Frequests_7120=DwIBAg=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=DAkLCjn8leYU-uJ-kfNEQMhPZWx9lzc4d5KgIR-RZWQ=v9sHqomCGBRWotign4NcwYwOpszOJehUGs_EO3eGn4SSZqxnfK7Iv15-X8nO1lii=h_jIP-6WcIjR6LssfGrV6Z2DojlN_w7Me4-a4rBE074=
>
> Jed Brown  writes:
>
>> 17 GB for a 1D DMDA, wow. :-)
>>
>> Could you try applying this diff to make it work for DMDA (it's currently 
>> handled by DMPlex)?
>>
>> diff --git i/src/dm/impls/da/fdda.c w/src/dm/impls/da/fdda.c
>> index cad4d926504..bd2a3bda635 100644
>> --- i/src/dm/impls/da/fdda.c
>> +++ w/src/dm/impls/da/fdda.c
>> @@ -675,19 +675,21 @@ PetscErrorCode DMCreateMatrix_DA(DM da, Mat *J)
>> specialized setting routines depend only on the particular preallocation
>> details of the matrix, not the type itself.
>>*/
>> -  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPIAIJSetPreallocation_C", ));
>> -  if (!aij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqAIJSetPreallocation_C", ));
>> -  if (!aij) {
>> -PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPIBAIJSetPreallocation_C", ));
>> -if (!baij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqBAIJSetPreallocation_C", ));
>> -if (!baij) {
>> -  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPISBAIJSetPreallocation_C", ));
>> -  if (!sbaij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqSBAIJSetPreallocation_C", ));
>> -  if (!sbaij) {
>> -PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPISELLSetPreallocation_C", ));
>> -if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqSELLSetPreallocation_C", ));
>> +  if (!dm->prealloc_skip) { // Flag is likely set when user intends to use 
>> MatSetPreallocationCOO()
>> +PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPIAIJSetPreallocation_C", ));
>> +if (!aij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqAIJSetPreallocation_C", ));
>> +if (!aij) {
>> +  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPIBAIJSetPreallocation_C", ));
>> +  if (!baij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqBAIJSetPreallocation_C", ));
>> +  if (!baij) {
>> +PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPISBAIJSetPreallocation_C", ));
>> +if (!sbaij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqSBAIJSetPreallocation_C", ));
>> +if (!sbaij) {
>> +  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatMPISELLSetPreallocation_C", ));
>> +  if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatSeqSELLSetPreallocation_C", ));
>> +}
>> +if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatISSetPreallocation_C", ));
>>}
>> -  if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
>> "MatISSetPreallocation_C", ));
>>  }
>>}
>>if (aij) {
>>
>>
>> "Fackler, Philip via petsc-users"  writes:
>>
>>> I'm using the following sequence of functions related to the Jacobian 
>>> matrix:
>>>
>>> DMDACreate1d(..., );
>>> DMSetFromOptions(da);
>>> DMSetUp(da);
>>> DMSetMatType(da, MATAIJKOKKOS);
>>> DMSetMatrixPreallocateSkip(da, P

Re: [petsc-users] Call to DMSetMatrixPreallocateSkip not changing allocation behavior

[Jed Brown]

I had a one-character typo in the diff above. This MR to release should work 
now.

https://gitlab.com/petsc/petsc/-/merge_requests/7120

Jed Brown  writes:

> 17 GB for a 1D DMDA, wow. :-)
>
> Could you try applying this diff to make it work for DMDA (it's currently 
> handled by DMPlex)?
>
> diff --git i/src/dm/impls/da/fdda.c w/src/dm/impls/da/fdda.c
> index cad4d926504..bd2a3bda635 100644
> --- i/src/dm/impls/da/fdda.c
> +++ w/src/dm/impls/da/fdda.c
> @@ -675,19 +675,21 @@ PetscErrorCode DMCreateMatrix_DA(DM da, Mat *J)
> specialized setting routines depend only on the particular preallocation
> details of the matrix, not the type itself.
>*/
> -  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPIAIJSetPreallocation_C", ));
> -  if (!aij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqAIJSetPreallocation_C", ));
> -  if (!aij) {
> -PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPIBAIJSetPreallocation_C", ));
> -if (!baij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqBAIJSetPreallocation_C", ));
> -if (!baij) {
> -  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPISBAIJSetPreallocation_C", ));
> -  if (!sbaij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqSBAIJSetPreallocation_C", ));
> -  if (!sbaij) {
> -PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPISELLSetPreallocation_C", ));
> -if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqSELLSetPreallocation_C", ));
> +  if (!dm->prealloc_skip) { // Flag is likely set when user intends to use 
> MatSetPreallocationCOO()
> +PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPIAIJSetPreallocation_C", ));
> +if (!aij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqAIJSetPreallocation_C", ));
> +if (!aij) {
> +  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPIBAIJSetPreallocation_C", ));
> +  if (!baij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqBAIJSetPreallocation_C", ));
> +  if (!baij) {
> +PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPISBAIJSetPreallocation_C", ));
> +if (!sbaij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqSBAIJSetPreallocation_C", ));
> +if (!sbaij) {
> +  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatMPISELLSetPreallocation_C", ));
> +  if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatSeqSELLSetPreallocation_C", ));
> +}
> +if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatISSetPreallocation_C", ));
>}
> -  if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
> "MatISSetPreallocation_C", ));
>  }
>}
>if (aij) {
>
>
> "Fackler, Philip via petsc-users"  writes:
>
>> I'm using the following sequence of functions related to the Jacobian matrix:
>>
>> DMDACreate1d(..., );
>> DMSetFromOptions(da);
>> DMSetUp(da);
>> DMSetMatType(da, MATAIJKOKKOS);
>> DMSetMatrixPreallocateSkip(da, PETSC_TRUE);
>> Mat J;
>> DMCreateMatrix(da, );
>> MatSetPreallocationCOO(J, ...);
>>
>> I recently added the call to DMSetMatrixPreallocateSkip, hoping the 
>> allocation would be delayed to MatSetPreallocationCOO, and that it would 
>> require less memory. The 
>> documentation<https://petsc.org/release/manualpages/DM/DMSetMatrixPreallocateSkip/>
>>  says that the data structures will not be preallocated. The following data 
>> from heaptrack shows that the allocation is still happening in the call to 
>> DMCreateMatrix.
>>
>> [cid:bda9ef12-a46f-47b2-9b9b-a4b2808b6b13]
>>
>> Can someone help me understand this?
>>
>> Thanks,
>>
>> Philip Fackler
>> Research Software Engineer, Application Engineering Group
>> Advanced Computing Systems Research Section
>> Computer Science and Mathematics Division
>> Oak Ridge National Laboratory

Re: [petsc-users] Call to DMSetMatrixPreallocateSkip not changing allocation behavior

[Jed Brown]

17 GB for a 1D DMDA, wow. :-)

Could you try applying this diff to make it work for DMDA (it's currently 
handled by DMPlex)?

diff --git i/src/dm/impls/da/fdda.c w/src/dm/impls/da/fdda.c
index cad4d926504..bd2a3bda635 100644
--- i/src/dm/impls/da/fdda.c
+++ w/src/dm/impls/da/fdda.c
@@ -675,19 +675,21 @@ PetscErrorCode DMCreateMatrix_DA(DM da, Mat *J)
specialized setting routines depend only on the particular preallocation
details of the matrix, not the type itself.
   */
-  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPIAIJSetPreallocation_C", ));
-  if (!aij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqAIJSetPreallocation_C", ));
-  if (!aij) {
-PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPIBAIJSetPreallocation_C", ));
-if (!baij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqBAIJSetPreallocation_C", ));
-if (!baij) {
-  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPISBAIJSetPreallocation_C", ));
-  if (!sbaij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqSBAIJSetPreallocation_C", ));
-  if (!sbaij) {
-PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPISELLSetPreallocation_C", ));
-if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqSELLSetPreallocation_C", ));
+  if (!dm->prealloc_skip) { // Flag is likely set when user intends to use 
MatSetPreallocationCOO()
+PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPIAIJSetPreallocation_C", ));
+if (!aij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqAIJSetPreallocation_C", ));
+if (!aij) {
+  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPIBAIJSetPreallocation_C", ));
+  if (!baij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqBAIJSetPreallocation_C", ));
+  if (!baij) {
+PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPISBAIJSetPreallocation_C", ));
+if (!sbaij) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqSBAIJSetPreallocation_C", ));
+if (!sbaij) {
+  PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatMPISELLSetPreallocation_C", ));
+  if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatSeqSELLSetPreallocation_C", ));
+}
+if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatISSetPreallocation_C", ));
   }
-  if (!sell) PetscCall(PetscObjectQueryFunction((PetscObject)A, 
"MatISSetPreallocation_C", ));
 }
   }
   if (aij) {


"Fackler, Philip via petsc-users"  writes:

> I'm using the following sequence of functions related to the Jacobian matrix:
>
> DMDACreate1d(..., );
> DMSetFromOptions(da);
> DMSetUp(da);
> DMSetMatType(da, MATAIJKOKKOS);
> DMSetMatrixPreallocateSkip(da, PETSC_TRUE);
> Mat J;
> DMCreateMatrix(da, );
> MatSetPreallocationCOO(J, ...);
>
> I recently added the call to DMSetMatrixPreallocateSkip, hoping the 
> allocation would be delayed to MatSetPreallocationCOO, and that it would 
> require less memory. The 
> documentation
>  says that the data structures will not be preallocated. The following data 
> from heaptrack shows that the allocation is still happening in the call to 
> DMCreateMatrix.
>
> [cid:bda9ef12-a46f-47b2-9b9b-a4b2808b6b13]
>
> Can someone help me understand this?
>
> Thanks,
>
> Philip Fackler
> Research Software Engineer, Application Engineering Group
> Advanced Computing Systems Research Section
> Computer Science and Mathematics Division
> Oak Ridge National Laboratory

Re: [petsc-dev] Matshell with PETSs solvers using GPU

[Jed Brown]

Han Tran  writes:

> Hi Jed,
>
> Thank you for your answer. I have not had a chance to work on this since I 
> asked. I have some follow-up questions.
>
> (1) From the Petsc manual, 
> https://petsc.org/release/manualpages/Vec/VecGetArrayAndMemType/, it shows 
> that both VecGetArrayAndMemType() and VecGetArrayReadAndMemType() do not have 
> Fortran support. Has Petsc added the Fortran support for these functions so 
> far?

It doesn't look like it. I think one would mirror the VecGetArrayF90 
implementation. 

> (2) My user-defined MatMult(A, u, v) already handles the communication, i.e., 
> the return vector v=A*u was computed with all needed communication. Thus, I 
> do not quite understand when you said that “use DMGlobalToLocalBegin/End()…”. 
> Do I need this function even if the communication is already done by my 
> user-defined MatMult()?

If you do your own communication, you don't need to use 
DMGlobalToLocalBegin/End.

>
> Thank you,
> Han
>
>> On Nov 4, 2022, at 9:06 AM, Jed Brown  wrote:
>> 
>> Yes, this is supported. You can use VecGetArrayAndMemType() to get access to 
>> device memory. You'll often use DMGlobalToLocalBegin/End() or VecScatter to 
>> communicate, but that will use GPU-aware MPI if your Vec is a device vector.
>> 
>> Han Tran  writes:
>> 
>>> Hi,
>>> 
>>> I am aware that PETSc recently supports solvers on GPU. I wonder whether 
>>> PETSc supports MatShell with GPU solvers, i.e., I have a user-defined 
>>> MatMult() function residing on the device, and I want to use MatShell 
>>> directly with PETSc GPU solvers without any transfer back and forth between 
>>> host and device. If this is possible, could you let me know how to do this 
>>> (an example, if any, would be very appreciated)?
>>> 
>>> Thank you!
>>> Han

[Vo]:Papers about the controversy

[Jed Rothwell]

Someone suggested I upload papers about the controversies in cold fusion,
and papers by skeptics. So I uploaded some papers about this. I mentioned
these two already:

*Editorials from the early history of cold fusion*, in *New York Times and
others*. 1989. (As I mentioned before)
http://lenr-canr.org/acrobat/editorials.pdf

APS, *Information from the APS meeting in Baltimore, May 1-2, 1989*. 1989.
http://lenr-canr.org/acrobat/APSinformatio.pdf

I added --

Two papers that were published together in New Scientist magazine:
Close, F., *Cold Fusion I: The Discovery That Never Was.* New Scientist,
1991. *1752*: p. 46.
Bockris, J., *Cold fusion II: The Story Continues.* New Scientist, 1991.
*1752*: p. 50.
http://lenr-canr.org/acrobat/CloseFwhateverha.pdf


Hoffman, N.J., *Book Review BAD SCIENCE The Short Life and Weird Times of
Cold Fusion.* Fusion Technol., 1994. *25*: p. 225.
http://lenr-canr.org/acrobat/HoffmanNJbookreview.pdf


Five papers about the controversy between Jones and Miles, which are
together in one file:

http://lenr-canr.org/acrobat/JonesSEexaminatio.pdf
The essence of the dispute was summarized by Miles in his second response:

"My journal publications criticized by Jones and Hansen report only
experimental results; hence, theoretical arguments are not germane to this
debate. In science, theory guides but experiments decide."


Miles said some unkind things about Jones, such as:

"More serious errors by S. E. Jones et al. are found in their presentation
of the electrochemical aspects of the cell operation. In particular, they
stated that the exchange current density depends on the electrode surface
area. The exchange current density always has dimensions of A/m2 or similar
units; hence, it cannot depend on the electrode surface area. Furthermore,
there is no such thing as an exchange current density for their reaction 4
in ref 8. This cell reaction consists of the oxidation of hydrogen at the
anode and the reduction of oxygen at the  cathode; hence, there are two
distinctly different exchange current densities associated with the cell
reaction."


(Jones said that current density depends on the surface area. That is a
geometry error. Current density is a function of surface area. It is as if
Jones said that mass density varies with volume. Or that joules per gram of
fuel depend on how many grams you have.)


Skeptics wrote many papers attempting to show theoretical reasons why cold
fusion is wrong. But there are only a few papers by skeptics that attempt
to find actual experimental errors. For a while I thought that Morrison
versus Fleischmann was the only one that was formally published in a
journal:

https://lenr-canr.org/acrobat/Fleischmanreplytothe.pdf

I knew there was a dispute between Jones and Miles. I have seen letters
between them. But I forgot that they both published journal papers about
this. So I should say that both Morrison and Jones attempted to find errors.

So did Shanahan. That is rather strange, and more like a theoretical
objection than an experimental one. As I recall, he does not point to any
specific experiment that has the problems he describes.


As always the most recent uploads are listed here:

https://lenr-canr.org/wordpress/?page_id=3009

Re: [petsc-users] Bug report VecNorm

[Jed Brown]

Pierre Jolivet  writes:

>> On 10 Dec 2023, at 8:40 AM, Stephan Köhler 
>>  wrote:
>> 
>> Dear PETSc/Tao team, 
>> 
>> there is a bug in the voector interface:  In the function 
>> VecNorm, see, eg. 
>> https://petsc.org/release/src/vec/vec/interface/rvector.c.html#VecNorm line 
>> 197 the check for consistency in line 214 is done on the wrong communicator. 
>>  The  communicator should be PETSC_COMM_SELF.
>> Otherwise the program may hang when PetscCheck is executed.
>
> I think the communicator should not be changed, but instead, the 
> check/conditional should be changed, à la PetscValidLogicalCollectiveBool().

I agree -- it's no extra cost to discover collectively whether all, none, or 
some have the norm. In this case, it could be a MPI_SUM, in which case the 
error message could report how many processes took each path.

Re: [petsc-users] PETSc and MPI-3/RMA

[Jed Brown]

It uses nonblocking point-to-point by default since that tends to perform 
better and is less prone to MPI implementation bugs, but you can select 
`-sf_type window` to try it, or use other strategies here depending on the sort 
of problem you're working with.

#define PETSCSFBASIC  "basic"
#define PETSCSFNEIGHBOR   "neighbor"
#define PETSCSFALLGATHERV "allgatherv"
#define PETSCSFALLGATHER  "allgather"
#define PETSCSFGATHERV"gatherv"
#define PETSCSFGATHER "gather"
#define PETSCSFALLTOALL   "alltoall"
#define PETSCSFWINDOW "window"

PETSc does try to use GPU-aware MPI, though implementation bugs are present on 
many machines and it often requires a delicate environment arrangement.

"Maeder  Alexander"  writes:

> I am a new user of PETSc
>
> and want to know more about the underlying implementation for matrix-vector 
> multiplication (Ax=y).
>
> PETSc utilizes a 1D distribution and communicates only parts of the vector x 
> utilized depending on the sparsity pattern of A.
>
> Is the communication of x done with MPI-3 RMA and utilizes cuda-aware mpi for 
> RMA?
>
>
> Best regards,
>
>
> Alexander Maeder

[Vo]:Information from the APS meeting in Baltimore, May 1-2, 1989

[Jed Rothwell]

I uploaded this infuriating collection of documents:


APS, *Information from the APS meeting in Baltimore, May 1-2, 1989*. 1989.


https://lenr-canr.org/acrobat/APSinformatio.pdf

Re: [Vo]:ICCF8 proceedings uploaded

[Jed Rothwell]

Robin  wrote:


> Do you have any personal highlights?
>

When they held this conference in 2000, the conference organizers told me I
had to ask individual authors to send me papers. Some authors were anxious
to have their work at LENR-CANR.org. Others did not want their work
uploaded. I ended up with several papers, listed here:

https://lenr-canr.org/wordpress/?page_id=2130#ICCF8

These include several that I liked, so I bugged the authors to send them.
Such as McKubre.


Miles added a postscript to this one in 2018:

https://lenr-canr.org/acrobat/MilesMcasestudie.pdf

I added a postscript taken from other papers by Fleischmann, explaining his
complicated heat transfer coefficient notation. I put this in my own paper
as well:

https://lenr-canr.org/acrobat/RothwellJreviewofth.pdf

You need a cheat sheet for Fleischmann's equations.

[Vo]:ICCF8 proceedings uploaded

[Jed Rothwell]

Proceedings uploaded:

Scaramuzzi, F., ed. *ICCF8 Proceedings of the 8th International Conference
on Cold Fusion*. Vol. 70. 2000, Italian Physical Society, Bologna, Italy:
Lerici (La Spezia), Italy.

https://lenr-canr.org/acrobat/Scaramuzziiccfprocee.pdf

This is a large document. It may take a while to download.

Re: [petsc-users] Reading VTK files in PETSc

[Jed Brown]

I assume you're working with a DA, in which case you can write in HDF5 format 
and add an Xdmf header so Paraview can read it. The utility 
lib/petsc/bin/petsc_gen_xdmf.py should be able to handle it.

I haven't written support for it (my problems are unstructured so I've focused 
on DMPlex), but the CGNS format supports structured meshes and that would be an 
efficient parallel format that doesn't need a header.

"Kevin G. Wang"  writes:

> Hi Jed,
>
> Thanks for your help! It does not have to be VTK (.vtr in my case). But I
> am trying to have a "seamless" workflow between reading, writing, and
> visualization, without the need of format conversions. I opted for VTK
> simply because it is easy to write, and can be directly visualized (using
> Paraview).
>
> Could you please advise as to what is the best practice in my scenario? My
> meshes are Cartesian, but non-uniform.
>
> Thanks,
> Kevin
>
> On Thu, Nov 30, 2023 at 1:02 AM Jed Brown  wrote:
>
>> Is it necessary that it be VTK format or can it be PETSc's binary format
>> or a different mesh format? VTK (be it legacy .vtk or the XML-based .vtu,
>> etc.) is a bad format for parallel reading, no matter how much effort might
>> go into an implementation.
>>
>> "Kevin G. Wang"  writes:
>>
>> > Good morning everyone.
>> >
>> > I use the following functions to output parallel vectors --- "globalVec"
>> in
>> > this example --- to VTK files. It works well, and is quite convenient.
>> >
>> > ~
>> >   PetscViewer viewer;
>> >   PetscViewerVTKOpen(PetscObjectComm((PetscObject)*dm), filename,
>> > FILE_MODE_WRITE, );
>> >   VecView(globalVec, viewer);
>> >   PetscViewerDestroy();
>> > ~
>> >
>> > Now, I am trying to do the opposite. I would like to read the VTK files
>> > generated by PETSc back into memory, and assign each one to a Vec. Could
>> > someone let me know how this can be done?
>> >
>> > Thanks!
>> > Kevin
>> >
>> >
>> > --
>> > Kevin G. Wang, Ph.D.
>> > Associate Professor
>> > Kevin T. Crofton Department of Aerospace and Ocean Engineering
>> > Virginia Tech
>> > 1600 Innovation Dr., VTSS Rm 224H, Blacksburg, VA 24061
>> > Office: (540) 231-7547  |  Mobile: (650) 862-2663
>> > URL: https://www.aoe.vt.edu/people/faculty/wang.html
>> > Codes: https://github.com/kevinwgy
>>
>
>
> -- 
> Kevin G. Wang, Ph.D.
> Associate Professor
> Kevin T. Crofton Department of Aerospace and Ocean Engineering
> Virginia Tech
> 1600 Innovation Dr., VTSS Rm 224H, Blacksburg, VA 24061
> Office: (540) 231-7547  |  Mobile: (650) 862-2663
> URL: https://www.aoe.vt.edu/people/faculty/wang.html
> Codes: https://github.com/kevinwgy

Re: [petsc-users] Reading VTK files in PETSc

[Jed Brown]

Is it necessary that it be VTK format or can it be PETSc's binary format or a 
different mesh format? VTK (be it legacy .vtk or the XML-based .vtu, etc.) is a 
bad format for parallel reading, no matter how much effort might go into an 
implementation.

"Kevin G. Wang"  writes:

> Good morning everyone.
>
> I use the following functions to output parallel vectors --- "globalVec" in
> this example --- to VTK files. It works well, and is quite convenient.
>
> ~
>   PetscViewer viewer;
>   PetscViewerVTKOpen(PetscObjectComm((PetscObject)*dm), filename,
> FILE_MODE_WRITE, );
>   VecView(globalVec, viewer);
>   PetscViewerDestroy();
> ~
>
> Now, I am trying to do the opposite. I would like to read the VTK files
> generated by PETSc back into memory, and assign each one to a Vec. Could
> someone let me know how this can be done?
>
> Thanks!
> Kevin
>
>
> -- 
> Kevin G. Wang, Ph.D.
> Associate Professor
> Kevin T. Crofton Department of Aerospace and Ocean Engineering
> Virginia Tech
> 1600 Innovation Dr., VTSS Rm 224H, Blacksburg, VA 24061
> Office: (540) 231-7547  |  Mobile: (650) 862-2663
> URL: https://www.aoe.vt.edu/people/faculty/wang.html
> Codes: https://github.com/kevinwgy

Re: [petsc-users] [Xolotl-psi-development] [EXTERNAL] Re: Unexpected performance losses switching to COO interface

[Jed Brown]

"Blondel, Sophie"  writes:

> Hi Jed,
>
> I'm not sure I'm going to reply to your question correctly because I don't 
> really understand how the split is done. Is it related to on diagonal and off 
> diagonal? If so, the off-diagonal part is usually pretty small (less than 20 
> DOFs) and related to diffusion, the diagonal part involves thousands of DOFs 
> for the reaction term.

>From the run-time option, it'll be a default (additive) split and we're 
>interested in the two diagonal blocks. One currently has a cheap solver that 
>would only be efficient with a well-conditioned positive definite matrix and 
>the other is using a direct solver ('redundant'). If you were to run with 
>-ksp_view and share the output, it would be informative.

Either way, I'd like to understand what physics are beind the equation 
currently being solved with 'redundant'. If it's diffusive, then algebraic 
multigrid would be a good place to start.

> Let us know what we can do to answer this question more accurately.
>
> Cheers,
>
> Sophie
> 
> From: Jed Brown 
> Sent: Tuesday, November 28, 2023 19:07
> To: Fackler, Philip ; Junchao Zhang 
> 
> Cc: petsc-users@mcs.anl.gov ; 
> xolotl-psi-developm...@lists.sourceforge.net 
> 
> Subject: Re: [Xolotl-psi-development] [petsc-users] [EXTERNAL] Re: Unexpected 
> performance losses switching to COO interface
>
> [Some people who received this message don't often get email from 
> j...@jedbrown.org. Learn why this is important at 
> https://aka.ms/LearnAboutSenderIdentification ]
>
> "Fackler, Philip via petsc-users"  writes:
>
>> That makes sense. Here are the arguments that I think are relevant:
>>
>> -fieldsplit_1_pc_type redundant -fieldsplit_0_pc_type sor -pc_type 
>> fieldsplit -pc_fieldsplit_detect_coupling​
>
> What sort of physics are in splits 0 and 1?
>
> SOR is not a good GPU algorithm, so we'll want to change that one way or 
> another. Are the splits of similar size or very different?
>
>> What would you suggest to make this better?
>>
>> Also, note that the cases marked "serial" are running on CPU only, that is, 
>> using only the SERIAL backend for kokkos.
>>
>> Philip Fackler
>> Research Software Engineer, Application Engineering Group
>> Advanced Computing Systems Research Section
>> Computer Science and Mathematics Division
>> Oak Ridge National Laboratory
>> 
>> From: Junchao Zhang 
>> Sent: Tuesday, November 28, 2023 15:51
>> To: Fackler, Philip 
>> Cc: petsc-users@mcs.anl.gov ; 
>> xolotl-psi-developm...@lists.sourceforge.net 
>> 
>> Subject: Re: [EXTERNAL] Re: [petsc-users] Unexpected performance losses 
>> switching to COO interface
>>
>> Hi, Philip,
>>I opened hpcdb-PSI_9-serial and it seems you used PCLU.  Since Kokkos 
>> does not have a GPU LU implementation, we do it on CPU via 
>> MatLUFactorNumeric_SeqAIJ(). Perhaps you can try other PC types?
>>
>> [Screenshot 2023-11-28 at 2.43.03 PM.png]
>> --Junchao Zhang
>>
>>
>> On Wed, Nov 22, 2023 at 10:43 AM Fackler, Philip 
>> mailto:fackle...@ornl.gov>> wrote:
>> I definitely dropped the ball on this. I'm sorry for that. I have new 
>> profiling data using the latest (as of yesterday) of petsc/main. I've put 
>> them in a single google drive folder linked here:
>>
>> https://drive.google.com/drive/folders/14ScvyfxOzc4OzXs9HZVeQDO-g6FdIVAI?usp=drive_link<https://urldefense.us/v2/url?u=https-3A__drive.google.com_drive_folders_14ScvyfxOzc4OzXs9HZVeQDO-2Dg6FdIVAI-3Fusp-3Ddrive-5Flink=DwMFaQ=v4IIwRuZAmwupIjowmMWUmLasxPEgYsgNI-O7C4ViYc=DAkLCjn8leYU-uJ-kfNEQMhPZWx9lzc4d5KgIR-RZWQ=Qn5D9xuzFcMdyuL0I2ruKmU6yeez0NrOx69oUjRaAXTeKD6etHt4USuZgnbqF4v6=_Lqg9v8aa4KXUdud3zqSp55FiYkZ12Pp5ZY54_9OvJI=>
>>
>> Have a happy holiday weekend!
>>
>> Thanks,
>>
>> Philip Fackler
>> Research Software Engineer, Application Engineering Group
>> Advanced Computing Systems Research Section
>> Computer Science and Mathematics Division
>> Oak Ridge National Laboratory
>> 
>> From: Junchao Zhang mailto:junchao.zh...@gmail.com>>
>> Sent: Monday, October 16, 2023 15:24
>> To: Fackler, Philip mailto:fackle...@ornl.gov>>
>> Cc: petsc-users@mcs.anl.gov<mailto:petsc-users@mcs.anl.gov> 
>> mailto:petsc-users@mcs.anl.gov>>; 
>> xolotl-psi-developm...@lists.sourceforge.net<mailto:xolotl-psi-developm...@lists.sourceforge.net>
>>  
>> mailto:xolotl-psi-developm...@lists.sourceforge.net>>
>> Subject: Re: [

Re: [petsc-users] [EXTERNAL] Re: Unexpected performance losses switching to COO interface

[Jed Brown]

"Fackler, Philip via petsc-users"  writes:

> That makes sense. Here are the arguments that I think are relevant:
>
> -fieldsplit_1_pc_type redundant -fieldsplit_0_pc_type sor -pc_type fieldsplit 
> -pc_fieldsplit_detect_coupling​

What sort of physics are in splits 0 and 1?

SOR is not a good GPU algorithm, so we'll want to change that one way or 
another. Are the splits of similar size or very different?

> What would you suggest to make this better?
>
> Also, note that the cases marked "serial" are running on CPU only, that is, 
> using only the SERIAL backend for kokkos.
>
> Philip Fackler
> Research Software Engineer, Application Engineering Group
> Advanced Computing Systems Research Section
> Computer Science and Mathematics Division
> Oak Ridge National Laboratory
> 
> From: Junchao Zhang 
> Sent: Tuesday, November 28, 2023 15:51
> To: Fackler, Philip 
> Cc: petsc-users@mcs.anl.gov ; 
> xolotl-psi-developm...@lists.sourceforge.net 
> 
> Subject: Re: [EXTERNAL] Re: [petsc-users] Unexpected performance losses 
> switching to COO interface
>
> Hi, Philip,
>I opened hpcdb-PSI_9-serial and it seems you used PCLU.  Since Kokkos does 
> not have a GPU LU implementation, we do it on CPU via 
> MatLUFactorNumeric_SeqAIJ(). Perhaps you can try other PC types?
>
> [Screenshot 2023-11-28 at 2.43.03 PM.png]
> --Junchao Zhang
>
>
> On Wed, Nov 22, 2023 at 10:43 AM Fackler, Philip 
> mailto:fackle...@ornl.gov>> wrote:
> I definitely dropped the ball on this. I'm sorry for that. I have new 
> profiling data using the latest (as of yesterday) of petsc/main. I've put 
> them in a single google drive folder linked here:
>
> https://drive.google.com/drive/folders/14ScvyfxOzc4OzXs9HZVeQDO-g6FdIVAI?usp=drive_link
>
> Have a happy holiday weekend!
>
> Thanks,
>
> Philip Fackler
> Research Software Engineer, Application Engineering Group
> Advanced Computing Systems Research Section
> Computer Science and Mathematics Division
> Oak Ridge National Laboratory
> 
> From: Junchao Zhang mailto:junchao.zh...@gmail.com>>
> Sent: Monday, October 16, 2023 15:24
> To: Fackler, Philip mailto:fackle...@ornl.gov>>
> Cc: petsc-users@mcs.anl.gov 
> mailto:petsc-users@mcs.anl.gov>>; 
> xolotl-psi-developm...@lists.sourceforge.net
>  
> mailto:xolotl-psi-developm...@lists.sourceforge.net>>
> Subject: Re: [EXTERNAL] Re: [petsc-users] Unexpected performance losses 
> switching to COO interface
>
> Hi, Philip,
>That branch was merged to petsc/main today. Let me know once you have new 
> profiling results.
>
>Thanks.
> --Junchao Zhang
>
>
> On Mon, Oct 16, 2023 at 9:33 AM Fackler, Philip 
> mailto:fackle...@ornl.gov>> wrote:
> Junchao,
>
> I've attached updated timing plots (red and blue are swapped from before; 
> yellow is the new one). There is an improvement for the NE_3 case only with 
> CUDA. Serial stays the same, and the PSI cases stay the same. In the PSI 
> cases, MatShift doesn't show up (I assume because we're using different 
> preconditioner arguments). So, there must be some other primary culprit. I'll 
> try to get updated profiling data to you soon.
>
> Thanks,
>
> Philip Fackler
> Research Software Engineer, Application Engineering Group
> Advanced Computing Systems Research Section
> Computer Science and Mathematics Division
> Oak Ridge National Laboratory
> 
> From: Fackler, Philip via Xolotl-psi-development 
> mailto:xolotl-psi-developm...@lists.sourceforge.net>>
> Sent: Wednesday, October 11, 2023 11:31
> To: Junchao Zhang mailto:junchao.zh...@gmail.com>>
> Cc: petsc-users@mcs.anl.gov 
> mailto:petsc-users@mcs.anl.gov>>; 
> xolotl-psi-developm...@lists.sourceforge.net
>  
> mailto:xolotl-psi-developm...@lists.sourceforge.net>>
> Subject: Re: [Xolotl-psi-development] [EXTERNAL] Re: [petsc-users] Unexpected 
> performance losses switching to COO interface
>
> I'm on it.
>
> Philip Fackler
> Research Software Engineer, Application Engineering Group
> Advanced Computing Systems Research Section
> Computer Science and Mathematics Division
> Oak Ridge National Laboratory
> 
> From: Junchao Zhang mailto:junchao.zh...@gmail.com>>
> Sent: Wednesday, October 11, 2023 10:14
> To: Fackler, Philip mailto:fackle...@ornl.gov>>
> Cc: petsc-users@mcs.anl.gov 
> mailto:petsc-users@mcs.anl.gov>>; 
> 

Re: [PRQ#51463] Orphan Request for parmetis

[Jed Brown]

The issue here is that upstream is effectively unmaintained so this version has 
patches for known bugs. (Patches have been submitted upstream with reproducers 
over the past decade, but upstream remains generally non-responsive unless 
cornered in the hallway at a conference.) These can be rebased on a new 
upstream version, but that takes some coordination and is normally done after 
upstream releases rather than random point commits. The workaround (if the bugs 
don't affect you) is to use parmetis-git.

Unfortunately, extra/metis is now incompatible. One fix would be to create a 
new metis51 required by parmetis (and parmetis-mpich) though we'd either have 
to make it provide metis or change the library name, which I think also 
requires build system patches. I've been busy to implement (and test) that 
solution, but simply making parmetis track git without the PETSc team's patch 
suite will cause breakage.

not...@aur.archlinux.org writes:

> MarsSeed [1] filed an orphan request for parmetis [2]:
>
> Please disown if not maintained.
> Reported failing to build since 2023-07-29, with solution provided.
>
> [1] https://aur.archlinux.org/account/MarsSeed/
> [2] https://aur.archlinux.org/pkgbase/parmetis/

Re: [Vo]:Video: Making activated palladium with Dr. Edmund Storms

[Jed Rothwell]

Robin  wrote:


> A few comments:-
>
> 1) I seem to recall someone else having used Calcium Oxide before.
>

Dufour in transmutation studies.

Iwamura also in transmutation studies.


Note that Ed explains the role of the inert calcium oxide particles here:

https://lenr-canr.org/acrobat/StormsEthenatureoc.pdf (starting on pages 4
and 5)

[Vo]:Video: Making activated palladium with Dr. Edmund Storms

[Jed Rothwell]

Wonderful!!

See:

https://www.youtube.com/watch?v=zjtPZR55r30

[Vo]:Claytor paper presented at NSF/EPRI Workshop in 1989

[Jed Rothwell]

I uploaded an early paper by Claytor:

Claytor, T.N., et al. *Tritium and neutron measurements of a solid state
cell*. in *NSF/EPRI Workshop on Anomalous Effects in Deuterated Materials*.
1989. Washington, DC.

https://lenr-canr.org/acrobat/ClaytorTNtritiumand.pdf

Abstract


A solid state "cold fusion" cell was constructed to test for
nonequilibrium D-D fusion in a solid. The stimulus for the design was the
hypothesis that the electrochemical surface layer in the Pons -Fleischmann
cell could be replaced with a metal- insulator-semiconductor (MIS) barrier.
Cells were constructed of alternating layers of palladium and silicon
powders pressed into a ceramic form and exposed to deuterium gas at 110
psia , resulting in a D/Pd ratio of 0.7. Pulses of current were passed
through the cells to populate nonequilibrium states at the MIS barriers.
One cell showed neutron activity and had a large amount of tritium. Other
cells have produced tritium at a low rate consistent with neutron emission
at or below the threshold of observability. The branching ratio for n/p was
about 3 x 10^-9 in all the experiments where a substantial amount of
tritium has been found.


One of the cells produced a substantial amount of tritium:

. . . [T]ritium analysis showed that cell 2 had 1300 times the fill gas
concentration of tritium, amounting to 3.5 x 10^15 atoms of tritium. This
level, although substantially above background, is equivalent to only 65
ppb.


The NSF/EPRI Workshop is described here:

http://lenr-canr.org/acrobat/EPRInsfepriwor.pdf

These experiments are also described here:

https://lenr-canr.org/acrobat/ClaytorTNtritiumgen.pdf

Several other experiments produced large amounts of tritium, such as
Bockris, Storms and Will. See:

https://lenr-canr.org/acrobat/WillFGtritiumgen.pdf

Skeptics ignore the tritium because it is compelling proof that cold fusion
is a nuclear reaction. They pretend that heat is not compelling, even
though it exceeds the limits of chemistry thousands of times over. They
want to claim that cold fusion does not produce clear evidence of a nuclear
reaction, even though anyone can see that it does. They mean it does not
produce the evidence *they want to see.* They are looking for proof that
cold fusion is actually plasma fusion, and it produces a deadly flux of
neutrons and no significant heat. They want that because it fits
their theories and -- more importantly -- because it means cold fusion has
no practical use, and does not threaten plasma fusion funding. Messinger
correctly described the infuriating, know-nothing attitude of the skeptics
at ARPA-E and elsewhere:

The hypothesis is that excess heat is caused by the release of nuclear
binding energy through low-energy nuclear reactions. But, as I have written
before, and ARPA-E stressed in their funding opportunity announcement, such
kind of evidence for LENR is insufficient due to the ambiguous nature of
heat . . .



I have uploaded a number of new papers lately:

https://lenr-canr.org/wordpress/?page_id=3009

Re: [Vo]:different temperatures

[Jed Rothwell]

Robin  wrote:


> I have an electric heater that can be controlled to within 1/10 of a
> degree centigrade . . .


That is remarkable. That is a laboratory grade thermostat.



> The only explanation I can think of is that the house is well insulated
> and has a long time constant, so that early in
> the morning the walls are still warm from the previous afternoon, while
> the air in the room is cool, thanks to contact
> with the cooler glass window, resulting in the thermostat registering a
> low temperature . . .


That is interesting. Put a thermometer near the windows. Get an IR camera!
(Borrow one . . . they are expensive.)

Re: [petsc-users] Storing Values using a Triplet for using later

[Jed Brown]

I don't think you want to hash floating point values, but I've had a number of 
reasons to want spatial hashing for near-neighbor queries in PETSc and that 
would be a great contribution. (Spatial hashes have a length scale and compute 
integer bins.)

Brandon Denton via petsc-users  writes:

> Good Afternoon,
>
> Is there a structure within PETSc that allows storage of a value using a 
> triple similar to PetscHMapIJSet with the key using a struct{PetscScalar i, 
> j, k;}?
>
> I'm trying to access mesh information (the shape function coefficients I will 
> calculate prior to their use) who's values I want to store in the auxiliary 
> array available in the Residual Functions of PETSc's FEM infrastructure. 
> After some trial and error work, I've come to the realization that the 
> coordinates (x[]) available in the auxiliary functions is the centroid of the 
> cell/element currently being evaluated. This triplet is unique for each 
> cell/element for a valid mesh so I think it's reasonable to use this triplet 
> as a key for looking up stored values unique to each cell/element. My plan is 
> to attached the map to the Application Context, also available to Auxiliary 
> Functions, to enable these calculations.
>
> Does such a map infrastructure exist within PETSc? If so, could you point me 
> to a reference for it? If not, does anyone have any suggestions on how to 
> solve this problem?
>
> Thank you in advance for your time.
> Brandon Denton

Re: [petsc-users] Better solver and preconditioner to use multiple GPU

[Jed Brown]

What sort of problem are you solving? Algebraic multigrid like gamg or hypre 
are good choices for elliptic problems. Sparse triangular solves have horrific 
efficiency even on one GPU so you generally want to do your best to stay away 
from them.

"Ramoni Z. Sedano Azevedo"  writes:

> Hey!
>
> I am using PETSC in Fortran code and we apply the MPI process to
> parallelize the code.
>
> At the moment, the options that have been used are
> -ksp_monitor_true_residual
> -ksp_type bcgs
> -pc_type bjacobi
> -sub_pc_type ilu
> -sub_pc_factor_levels 3
> -sub_pc_factor_fill 6
>
> Now, we want to use multiple GPUs and I would like to know if there is a
> better solver and preconditioner pair to apply in this case.
>
> Yours sincerely,
> Ramoni Z. S . Azevedo

Re: [petsc-users] Status of PETScSF failures with GPU-aware MPI on Perlmutter

[Jed Brown]

What modules do you have loaded. I don't know if it currently works with 
cuda-11.7. I assume you're following these instructions carefully.

https://docs.nersc.gov/development/programming-models/mpi/cray-mpich/#cuda-aware-mpi

In our experience, GPU-aware MPI continues to be brittle on these machines. 
Maybe you can inquire with NERSC exactly which CUDA versions are tested with 
GPU-aware MPI.

Sajid Ali  writes:

> Hi PETSc-developers,
>
> I had posted about crashes within PETScSF when using GPU-aware MPI on
> Perlmutter a while ago (
> https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2022-February/045585.html).
> Now that the software stacks have stabilized, I was wondering if there was
> a fix for the same as I am still observing similar crashes.
>
> I am attaching the trace of the latest crash (with PETSc-3.20.0) for
> reference.
>
> Thank You,
> Sajid Ali (he/him) | Research Associate
> Data Science, Simulation, and Learning Division
> Fermi National Accelerator Laboratory
> s-sajid-ali.github.io

Re: [VOTE] October 2023 PR of the Month

[Jed Cunningham]

I'm slightly embarrassed I forgot about 34729, but yeah changing my vote to
that as well. Now (at least so far) it's unanimous :)

Re: [VOTE] October 2023 PR of the Month

[Jed Cunningham]

The new OpenSearch provider gets my vote - 34705.

Re: [petsc-users] Advices on creating DMPlex from custom input format

[Jed Brown]

It's probably easier to apply boundary conditions when you have the serial 
mesh. You may consider contributing the reader if it's a format that others use.

"onur.notonur via petsc-users"  writes:

> Hi,
>
> I hope this message finds you all in good health and high spirits.
>
> I wanted to discuss an approach problem input file reading/processing in a 
> solver which is using PETSc DMPlex. In our team we have a range of solvers, 
> they are not built on PETSc except this one, but they all share a common 
> problem input format. This format includes essential data such as node 
> coordinates, element connectivity, boundary conditions based on elements, and 
> specific metadata related to the problem. I create an array for boundary 
> points on each rank and utilize them in our computations, I am doing it 
> hardcoded currently but I need to start reading those input files, But I am 
> not sure about the approach.
>
> Here's what I have in mind:
>
> - - Begin by reading the node coordinates and connectivity on a single core.
> - Utilize the DMPlexCreateFromCellListPetsc() function to construct the 
> DMPlex.
> - Distribute the mesh across processors.
> - Proceed to read and process the boundary conditions on each processor. If 
> the global index of the boundary element corresponds to that processor, we 
> process it; otherwise, we pass.
>
> Additionally, maybe I need to reorder the mesh. In that case I think I can 
> use the point permutation IS obtained from the DMPlexGetOrdering() function 
> while processing boundary conditions.
>
> Also I have another approach in my mind but I don't know if it's possible: 
> Read/construct DMPlex on single core including boundary conditions. Store BC 
> related data in Vec or another appropriate data structure. Then distribute 
> this BC holding data structure too as well as DMPlex.
>
> I would greatly appreciate your thoughts and any suggestions you might have 
> regarding this approach. Looking forward to hearing your insights.
>
> Best regards,
>
> Onur

Re: [VOTE] Add Multiple PR's of the Month to the Airflow Newsletter

[Jed Cunningham]

Just to clarify, I didn't mean we should highlight multiple PRs every
month. In that month none of @eumiro's PRs were individually enough to be
highlighted but in bulk they were. That was an unusual situation though.

I think we should be flexible with it. I'm not opposed to having multiple
per month, but if we do I think they should be equally notable. If we have
a clear winner, we should just highlight that one PR. My 2c.

I'll also call out that we (committers, community members, anyone really!)
should toss protm on good candidates as we are reviewing stuff day-to-day.
That bumps up the score in the script and will help ensure the good stuff
bubbles to the top of the scripts output! A quick search shows we've done
this less than a dozen times so far.

Re: [VOTE] Add providers for Pinecone, OpenAI & Cohere to enable first-class LLMOps

[Jed Cunningham]

+1 (binding)

Re: [petsc-users] Copying PETSc Objects Across MPI Communicators

[Jed Brown]

You can place it in a parallel Mat (that has rows or columns on only one rank 
or a subset of ranks) and then MatCreateSubMatrix with all new rows/columns on 
a different rank or subset of ranks.

That said, you usually have a function that assembles the matrix and you can 
just call that on the new communicator.

Damyn Chipman  writes:

> Hi PETSc developers,
>
> In short, my question is this: Does PETSc provide a way to move or copy an 
> object (say a Mat) from one communicator to another?
>
> The more detailed scenario is this: I’m working on a linear algebra solver on 
> quadtree meshes (i.e., p4est). I use communicator subsets in order to 
> facilitate communication between siblings or nearby neighbors. When 
> performing linear algebra across siblings (a group of 4), I need to copy a 
> node’s data (i.e., a Mat object) from a sibling’s communicator to the 
> communicator that includes the four siblings. From what I can tell, I can 
> only copy a PETSc object onto the same communicator.
>
> My current approach will be to copy the raw data from the Mat on one 
> communicator to a new Mat on the new communicator, but I wanted to see if 
> there is a more “elegant” approach within PETSc.
>
> Thanks in advance,
>
> Damyn Chipman
> Boise State University
> PhD Candidate
> Computational Sciences and Engineering
> damynchip...@u.boisestate.edu

[Vo]:Slides from Robert Duncan

[Jed Rothwell]

U.S. DoE

Advanced Materials Characterization and Nuclear Product Detection for LENR
Robert V. Duncan, Ph.D. President’s Distinguished Chair in Physics and
Professor of Physics Texas Tech University Washington, DC
September 8, 2023

https://arpa-e.energy.gov/sites/default/files/2023-09/05_Duncan_Performer.pdf

Re: [VOTE] Airflow Providers prepared on October 13, 2023

[Jed Cunningham]

1 (binding)

Checked signatures, checksums, licences

Re: [VOTE] Release Airflow 2.7.2 from 2.7.2rc1

[Jed Cunningham]

+1 (binding)

Checked signatures, checksums, licences, compared sources. Used it with the
helm chart with a few different configs

Re: [petsc-users] FEM Implementation of NS with SUPG Stabilization

[Jed Brown]

Matthew Knepley  writes:

> On Wed, Oct 11, 2023 at 1:03 PM Jed Brown  wrote:
>
>> I don't see an attachment, but his thesis used conservative variables and
>> defined an effective length scale in a way that seemed to assume constant
>> shape function gradients. I'm not aware of systematic literature comparing
>> the covariant and contravariant length measures on anisotropic meshes, but
>> I believe most people working in the Shakib/Hughes approach use the
>> covariant measure. Our docs have a brief discussion of this choice.
>>
>> https://libceed.org/en/latest/examples/fluids/#equation-eq-peclet
>>
>> Matt, I don't understand how the second derivative comes into play as a
>> length measure on anistropic meshes -- the second derivatives can be
>> uniformly zero and yet you still need a length measure.
>>
>
> I was talking about the usual SUPG where we just penalize the true residual.

I think you're focused on computing the strong diffusive flux (which can be 
done using second derivatives or by a projection; the latter produces somewhat 
better results). But you still need a length scale and that's most naturally 
computed using the derivative of reference coordinates with respect to physical 
(or equivalently, the associated metric tensor).

Re: [petsc-users] FEM Implementation of NS with SUPG Stabilization

[Jed Brown]

I don't see an attachment, but his thesis used conservative variables and 
defined an effective length scale in a way that seemed to assume constant shape 
function gradients. I'm not aware of systematic literature comparing the 
covariant and contravariant length measures on anisotropic meshes, but I 
believe most people working in the Shakib/Hughes approach use the covariant 
measure. Our docs have a brief discussion of this choice.

https://libceed.org/en/latest/examples/fluids/#equation-eq-peclet

Matt, I don't understand how the second derivative comes into play as a length 
measure on anistropic meshes -- the second derivatives can be uniformly zero 
and yet you still need a length measure.

Brandon Denton via petsc-users  writes:

> I was thinking about trying to implement Ben Kirk's approach to Navier-Stokes 
> (see attached paper; Section 5). His approach uses these quantities to align 
> the orientation of the unstructured element/cell with the fluid velocity to 
> apply the stabilization/upwinding and to detect shocks.
>
> If you have an example of the approach you mentioned, could you please send 
> it over so I can review it?
>
> On Oct 11, 2023 6:02 AM, Matthew Knepley  wrote:
> On Tue, Oct 10, 2023 at 9:34 PM Brandon Denton via petsc-users 
> mailto:petsc-users@mcs.anl.gov>> wrote:
> Good Evening,
>
> I am looking to implement a form of Navier-Stokes with SUPG Stabilization and 
> shock capturing using PETSc's FEM infrastructure. In this implementation, I 
> need access to the cell's shape function gradients and natural coordinate 
> gradients for calculations within the point-wise residual calculations. How 
> do I get these quantities at the quadrature points? The signatures for fo and 
> f1 don't seem to contain this information.
>
> Are you sure you need those? Darsh and I implemented SUPG without that. You 
> would need local second derivative information, which you can get using 
> -dm_ds_jet_degree 2. If you check in an example, I can go over it.
>
>   Thanks,
>
>  Matt
>
> Thank you in advance for your time.
> Brandon
>
>
> --
> What most experimenters take for granted before they begin their experiments 
> is infinitely more interesting than any results to which their experiments 
> lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/

Re: [petsc-users] FEM Implementation of NS with SUPG Stabilization

[Jed Brown]

Do you want to write a new code using only PETSc or would you be up for 
collaborating on ceed-fluids, which is a high-performance compressible SUPG 
solver based on DMPlex with good GPU support? It uses the metric to compute 
covariant length for stabilization. We have YZƁ shock capturing, though it 
hasn't been tested much beyond shock tube experiments. (Most of our work has 
been low Mach.)

https://libceed.org/en/latest/examples/fluids/
https://github.com/CEED/libCEED/blob/main/examples/fluids/qfunctions/stabilization.h#L76


On Tue, Oct 10, 2023, at 7:34 PM, Brandon Denton via petsc-users wrote:
> Good Evening,
> 
> I am looking to implement a form of Navier-Stokes with SUPG Stabilization and 
> shock capturing using PETSc's FEM infrastructure. In this implementation, I 
> need access to the cell's shape function gradients and natural coordinate 
> gradients for calculations within the point-wise residual calculations. How 
> do I get these quantities at the quadrature points? The signatures for fo and 
> f1 don't seem to contain this information.
> 
> Thank you in advance for your time.
> Brandon

[ANNOUNCE] Apache Airflow Helm Chart version 1.11.0 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.11.0  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.11.0/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.11.0/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.11.0/quick-start.html
️   Release Notes:
https://airflow.apache.org/docs/helm-chart/1.11.0/release_notes.html

Thanks to all the contributors who made this possible.

Cheers,
Jed

[ANNOUNCE] Apache Airflow Helm Chart version 1.11.0 Released

[Jed Cunningham]

Dear Airflow community,

I am pleased to announce that we have released Apache Airflow Helm chart
1.11.0  

The source release, as well as the "binary" Helm Chart release, are
available:

   Official Sources:
https://airflow.apache.org/docs/helm-chart/1.11.0/installing-helm-chart-from-sources.html
   ArtifactHub:
https://artifacthub.io/packages/helm/apache-airflow/airflow
   Docs: https://airflow.apache.org/docs/helm-chart/1.11.0/
   Quick Start Installation Guide:
https://airflow.apache.org/docs/helm-chart/1.11.0/quick-start.html
️   Release Notes:
https://airflow.apache.org/docs/helm-chart/1.11.0/release_notes.html

Thanks to all the contributors who made this possible.

Cheers,
Jed

[RESULT][VOTE] Release Apache Airflow Helm Chart 1.11.0 based on 1.11.0rc2

[Jed Cunningham]

Hello all,

The vote to release Apache Airflow Helm Chart version 1.11.0 based on
1.11.0rc2 is now closed.

The vote PASSED with 3 binding "+1", 2 non-binding "+1" and 0 "-1" votes:

"+1" Binding votes:

  - Jed Cunningham
  - Hussein Awala
  - Daniel Standish

"+1" Non-Binding votes:

  - Amogh Desai
  - Utkarsh Sharma

Vote thread:https://lists.apache.org/thread/wyoz9g7cldym3f6x4cnhvzsy76hgq0h5

I'll continue with the release process and the release announcement
will follow shortly.

Thanks,
Jed