Introduction​

A reference square element is given by

For heirarchical basis the master reference element is given by:

For lagrange polynomials the master reference element is give by:

Please note the difference in ordering and orientation of edges.

Getting interpolation points​

To get the interpolation points on reference quadrangle for Lagrange polynomials we use the method call InterpolationPoint_Quadrangle

There are two ways to call this routine. For isotropic polynomial interpolation we use the following interface.

  FUNCTION InterpolationPoint_Quadrangle1(order, ipType, &
    & layout, xij, alpha, beta, lambda) RESULT(ans)
  END FUNCTION InterpolationPoint_Quadrangle1

You can learn about this method at InterpolationPoint_Quadrangle

There is another method for getting interpolation points for anisotropic interpolation, the interface is given below:

FUNCTION InterpolationPoint_Quadrangle2(  &
  & p, q, ipType1, ipType2, layout, xij, alpha1, beta1, &
  & lambda1, alpha2, beta2, lambda2) RESULT(ans)
END FUNCTION InterpolationPoint_Quadrangle2

Getting quadrature points​

TODO

Getting Lagrange polynomials​

We can use the method called LagrangeEvallAll_Quadrangle to get the value of Lagrange polynomials at specified points in the reference elements.

Note that the polynomials should be evaluated inside the reference element, that is, biunit quadrangle.

There are a few ways to call LagrangeEvalAll_Quadrangle function.

The first method is given below. This method evaluates all the lagrange polynomials at a single point.

  FUNCTION LagrangeEvalAll_Quadrangle( &
    & order, &
    & x, &
    & xij, &
    & coeff, &
    & firstCall, &
    & basisType, &
    & alpha, &
    & beta, &
    & lambda) RESULT(ans)

You can learn more about this method at LagrangeEvallAll_Quadrangle.

The second method is given below. This method evaluates all the Lagrange polynomials at several given points.

  FUNCTION LagrangeEvalAll_Quadrangle( &
    & order, &
    & x, &
    & xij, &
    & coeff, &
    & firstCall, &
    & basisType, &
    & alpha, &
    & beta, &
    & lambda &
    & ) RESULT(ans)

Getting Heirarchical Basis​

To get all the heirarchical basis we use the function HeirarchicalBasis_Quadrangle.

FUNCTION HeirarchicalBasis_Quadrangle(p, q, xij) RESULT(ans)

In this case p and q are order of polynomial in x and y directions.

If you want to specify the order of polynomial on edges and cell, then you can use the following method.

FUNCTION HeirarchicalBasis_Quadrangle(pb, qb, pe3, pe4, &
  & qe1, qe2, xij) RESULT(ans)

• The first four basis are vertex basis
• Then, edge bubble basis
• Finally, we have cell bubble basis.

Introduction​

A codespace is a development environment that's hosted in the cloud. You can customize your project for GitHub Codespaces by committing configuration files to your repository (often known as Configuration-as-Code), which creates a repeatable codespace configuration for all users of your project.

Each codespace you create is hosted by GitHub in a Docker container, running on a virtual machine. You can choose from a selection of virtual machine types, from 2 cores, 8 GB RAM, and 32 GB storage, up to 32 cores, 64 GB RAM, and 128 GB storage.

By default, codespaces are created from an Ubuntu Linux image that includes a selection of popular languages and tools, but you can use an image based on a Linux distribution of your choice and configure it for your particular requirements. Regardless of your local operating system, your codespace will run in a Linux environment. Windows and MacOS are not supported operating systems for the remote container.

You can connect to your codespaces from your browser, from Visual Studio Code, from the JetBrains Gateway application, or by using GitHub CLI. When you connect, you are placed within the Docker container. You do not have access to the outer Linux virtual machine host.

The lifecycle of a codespace begins when you create a codespace and ends when you delete it. You can disconnect and reconnect to an active codespace without affecting its running processes. You may stop and restart a codespace without losing changes that you have made to your project.

When you want to work on a project, you can choose to create a new codespace or open an existing codespace. You might want to create a new codespace from a branch of your repository each time you develop in GitHub Codespaces or keep a long-running codespace for a feature. If you're starting a new project, you might want to create a codespace from a template and publish to a repository on GitHub later.

If you choose to create a new codespace each time you work on a project, you should regularly push your changes so that any new commits are on GitHub. If you choose to use a long-running codespace for your project, you should pull from your repository's default branch each time you start working in your codespace so that your environment has the latest commits. This workflow is very similar to if you were working with a project on your local machine.

To speed up codespace creation, repository administrators can enable GitHub Codespaces prebuilds for a repository. For more information, see "About GitHub Codespaces prebuilds."